In-running wagering

ABSTRACT

Methods and systems are provided herewith for creating and managing wagers on possible states within a live event, such as possible outcomes of subparts of a sporting event or other possible occurrences within the event. An initial state and multiple possible future states of a performance parameter of the event are determined based on state information of the event. A betting market may be created by determining probabilities and odds for the possible future states. Bets may be made on the possible future states via a touch-sensitive display. A payout may be made to a winner who selects a possible future state that actually occurs.

RELATED APPLICATIONS

This application is a continuation of U.S. application Ser. No.13/612,084 filed Sep. 12, 2012, which is a continuation of U.S.application Ser. No. 12/497,668, filed Jul. 4, 2009 (now U.S. Pat. No.8,342,946 issued on Jan. 1, 2013), which is a continuation-in-part ofU.S. application Ser. No. 12/258,297, filed Oct. 24, 2008 (now U.S. Pat.No. 8,342,966 issued on Jan. 1, 2013), the disclosures of which areincorporated herein by reference in their entireties.

FIELD OF INVENTION

This invention relates to systems and methods for enabling users towager on an outcome of an event.

BRIEF DESCRIPTION OF THE FIGURES

FIG. 1 depicts a system according to at least one embodiment of thesystems disclosed herein;

FIG. 2 depicts a system according to at least one embodiment of thesystems disclosed herein;

FIG. 3 depicts a flow diagram according to at least one embodiment ofthe methods disclosed herein;

FIGS. 4A and 4B depict exemplary gaming tables for use in at least oneembodiment of the methods and systems disclosed herein;

FIGS. 5A-5C depict exemplary interface screens for use in at least oneembodiment of the methods and systems disclosed herein;

FIG. 6 depicts exemplary referee animation images for use in at leastone embodiment of the methods and systems disclosed herein;

FIG. 7 depicts an exemplary interface screen for use in at least oneembodiment of the methods and systems disclosed herein;

FIG. 8 depicts an exemplary interface screen for use in at least oneembodiment of the methods and systems disclosed herein;

FIG. 9 depicts an exemplary interface screen for use in at least oneembodiment of the methods and systems disclosed herein; and

FIG. 10 depicts an exemplary interface screen for use in at least oneembodiment of the methods and systems disclosed herein.

FIG. 11 depicts an exemplary interface screen for use in at least oneembodiment of the methods and systems disclosed herein.

FIG. 12 depicts an exemplary interface screen for use in at least oneembodiment of the methods and systems disclosed herein.

FIG. 13 depicts an exemplary interface screen for use in at least oneembodiment of the methods and systems disclosed herein.

FIG. 14 depicts an exemplary interface screen for use in at least oneembodiment of the methods and systems disclosed herein.

FIG. 15 depicts an exemplary interface screen for use in at least oneembodiment of the methods and systems disclosed herein.

FIG. 16 depicts an exemplary interface screen for use in at least oneembodiment of the methods and systems disclosed herein.

FIG. 17 depicts an exemplary interface screen for use in at least oneembodiment of the methods and systems disclosed herein.

FIGS. 11-19 depict exemplary user interfaces for use in variousembodiments of the methods and systems disclosed herein, e.g., forvarious different types of sporting events.

DETAILED DESCRIPTION

The following sections I-XI provide a guide to interpreting the presentapplication.

I. Terms

The term “product” means any machine, manufacture and/or composition ofmatter, unless expressly specified otherwise.

The term “process” means any process, algorithm, method or the like,unless expressly specified otherwise.

Each process (whether called a method, algorithm or otherwise)inherently includes one or more steps, and therefore all references to a“step” or “steps” of a process have an inherent antecedent basis in themere recitation of the term ‘process’ or a like term. Accordingly, anyreference in a claim to a ‘step’ or ‘steps’ of a process has sufficientantecedent basis.

The term “invention” and the like mean “the one or more inventionsdisclosed in this application”, unless expressly specified otherwise.

The terms “an embodiment”, “embodiment”, “embodiments”, “theembodiment”, “the embodiments”, “one or more embodiments”, “someembodiments”, “certain embodiments”, “one embodiment”, “anotherembodiment” and the like mean “one or more (but not all) embodiments ofthe disclosed invention(s)”, unless expressly specified otherwise.

The term “variation” of an invention means an embodiment of theinvention, unless expressly specified otherwise.

A reference to “another embodiment” in describing an embodiment does notimply that the referenced embodiment is mutually exclusive with anotherembodiment (e.g., an embodiment described before the referencedembodiment), unless expressly specified otherwise.

The terms “including”, “comprising” and variations thereof mean“including but not limited to”, unless expressly specified otherwise.

The terms “a”, “an” and “the” mean “one or more”, unless expresslyspecified otherwise.

The term “plurality” means “two or more”, unless expressly specifiedotherwise.

The term “herein” means “in the present application, including anythingwhich may be incorporated by reference”, unless expressly specifiedotherwise.

The phrase “at least one of”, when such phrase modifies a plurality ofthings (such as an enumerated list of things) means any combination ofone or more of those things, unless expressly specified otherwise. Forexample, the phrase “at least one of a widget, a car and a wheel” meanseither (i) a widget, (ii) a car, (iii) a wheel, (iv) a widget and a car,(v) a widget and a wheel, (vi) a car and a wheel, or (vii) a widget, acar and a wheel. The phrase “at least one of”, when such phrase modifiesa plurality of things does not mean “one of each of” the plurality ofthings.

Numerical terms such as “one”, “two”, etc. when used as cardinal numbersto indicate quantity of something (e.g., one widget, two widgets), meanthe quantity indicated by that numerical term, but do not mean at leastthe quantity indicated by that numerical term. For example, the phrase“one widget” does not mean “at least one widget”, and therefore thephrase “one widget” does not cover, e.g., two widgets.

The phrase “based on” does not mean “based only on”, unless expresslyspecified otherwise. In other words, the phrase “based on” describesboth “based only on” and “based at least on”. The phrase “based at leaston” is equivalent to the phrase “based at least in part on”.

The term “represent” and like terms are not exclusive, unless expresslyspecified otherwise. For example, the term “represents” does not mean“represents only”, unless expressly specified otherwise. In other words,the phrase “the data represents a credit card number” describes both“the data represents only a credit card number” and “the data representsa credit card number and the data also represents something else”.

The term “whereby” is used herein only to precede a clause or other setof words that express only the intended result, objective or consequenceof something that is previously and explicitly recited. Thus, when theterm “whereby” is used in a claim, the clause or other words that theterm “whereby” modifies do not establish specific further limitations ofthe claim or otherwise restricts the meaning or scope of the claim.

The term “e.g.” and like terms mean “for example”, and thus does notlimit the term or phrase it explains. For example, in the sentence “thecomputer sends data (e.g., instructions, a data structure) over theInternet”, the term “e.g.” explains that “instructions” are an exampleof “data” that the computer may send over the Internet, and alsoexplains that “a data structure” is an example of “data” that thecomputer may send over the Internet. However, both “instructions” and “adata structure” are merely examples of “data”, and other things besides“instructions” and “a data structure” can be “data”.

The term “respective” and like terms mean “taken individually”. Thus iftwo or more things have “respective” characteristics, then each suchthing has its own characteristic, and these characteristics can bedifferent from each other but need not be. For example, the phrase “eachof two machines has a respective function” means that the first suchmachine has a function and the second such machine has a function aswell. The function of the first machine may or may not be the same asthe function of the second machine.

The term “i.e.” and like terms mean “that is”, and thus limits the termor phrase it explains. For example, in the sentence “the computer sendsdata (i.e., instructions) over the Internet”, the term “i.e.” explainsthat “instructions” are the “data” that the computer sends over theInternet.

Any given numerical range shall include whole and fractions of numberswithin the range. For example, the range “1 to 10” shall be interpretedto specifically include whole numbers between 1 and 10 (e.g., 1, 2, 3,4, . . . 9) and non-whole numbers (e.g., 1.1, 1.2, . . . 1.9).

Where two or more terms or phrases are synonymous (e.g., because of anexplicit statement that the terms or phrases are synonymous), instancesof one such term/phrase does not mean instances of another suchterm/phrase must have a different meaning. For example, where astatement renders the meaning of “including” to be synonymous with“including but not limited to”, the mere usage of the phrase “includingbut not limited to” does not mean that the term “including” meanssomething other than “including but not limited to”.

II. Determining

The term “determining” and grammatical variants thereof (e.g., todetermine a price, determining a value, determine an object which meetsa certain criterion) is used in an extremely broad sense. The term“determining” encompasses a wide variety of actions and therefore“determining” can include calculating, computing, processing, deriving,investigating, looking up (e.g., looking up in a table, a database oranother data structure), ascertaining and the like. Also, “determining”can include receiving (e.g., receiving information), accessing (e.g.,accessing data in a memory) and the like. Also, “determining” caninclude resolving, selecting, choosing, establishing, and the like.

The term “determining” does not imply certainty or absolute precision,and therefore “determining” can include estimating, extrapolating,predicting, guessing and the like.

The term “determining” does not imply that mathematical processing mustbe performed, and does not imply that numerical methods must be used,and does not imply that an algorithm or process is used.

The term “determining” does not imply that any particular device must beused. For example, a computer need not necessarily perform thedetermining.

III. Forms of Sentences

Where a limitation of a first claim would cover one of a feature as wellas more than one of a feature (e.g., a limitation such as “at least onewidget” covers one widget as well as more than one widget), and where ina second claim that depends on the first claim, the second claim uses adefinite article “the” to refer to the limitation (e.g., “the widget”),this does not imply that the first claim covers only one of the feature,and this does not imply that the second claim covers only one of thefeature (e.g., “the widget” can cover both one widget and more than onewidget).

When an ordinal number (such as “first”, “second”, “third” and so on) isused as an adjective before a term, that ordinal number is used (unlessexpressly specified otherwise) merely to indicate a particular feature,such as to distinguish that particular feature from another feature thatis described by the same term or by a similar term. For example, a“first widget” may be so named merely to distinguish it from, e.g., a“second widget”. Thus, the mere usage of the ordinal numbers “first” and“second” before the term “widget” does not indicate any otherrelationship between the two widgets, and likewise does not indicate anyother characteristics of either or both widgets. For example, the mereusage of the ordinal numbers “first” and “second” before the term“widget” (1) does not indicate that either widget comes before or afterany other in order or location; (2) does not indicate that either widgetoccurs or acts before or after any other in time; and (3) does notindicate that either widget ranks above or below any other, as inimportance or quality. In addition, the mere usage of ordinal numbersdoes not define a numerical limit to the features identified with theordinal numbers. For example, the mere usage of the ordinal numbers“first” and “second” before the term “widget” does not indicate thatthere must be no more than two widgets.

When a single device, article or other product is described herein, morethan one device/article (whether or not they cooperate) mayalternatively be used in place of the single device/article that isdescribed. Accordingly, the functionality that is described as beingpossessed by a device may alternatively be possessed by more than onedevice/article (whether or not they cooperate).

Similarly, where more than one device, article or other product isdescribed herein (whether or not they cooperate), a singledevice/article may alternatively be used in place of the more than onedevice or article that is described. For example, a plurality ofcomputer-based devices may be substituted with a single computer-baseddevice. Accordingly, the various functionality that is described asbeing possessed by more than one device or article may alternatively bepossessed by a single device/article.

The functionality and/or the features of a single device that isdescribed may be alternatively embodied by one or more other deviceswhich are described but are not explicitly described as having suchfunctionality/features. Thus, other embodiments need not include thedescribed device itself, but rather can include the one or more otherdevices which would, in those other embodiments, have suchfunctionality/features.

IV. Disclosed Examples and Terminology are not Limiting

Neither the Title (set forth at the beginning of the first page of thepresent application) nor the Abstract (set forth at the end of thepresent application) is to be taken as limiting in any way as the scopeof the disclosed invention(s), is to be used in interpreting the meaningof any claim or is to be used in limiting the scope of any claim. AnAbstract has been included in this application merely because anAbstract is required under 37 C.F.R. §1.72(b).

The title of the present application and headings of sections providedin the present application are for convenience only, and are not to betaken as limiting the disclosure in any way.

Numerous embodiments are described in the present application, and arepresented for illustrative purposes only. The described embodiments arenot, and are not intended to be, limiting in any sense. The presentlydisclosed invention(s) are widely applicable to numerous embodiments, asis readily apparent from the disclosure. One of ordinary skill in theart will recognize that the disclosed invention(s) may be practiced withvarious modifications and alterations, such as structural, logical,software, and electrical modifications. Although particular features ofthe disclosed invention(s) may be described with reference to one ormore particular embodiments and/or drawings, it should be understoodthat such features are not limited to usage in the one or moreparticular embodiments or drawings with reference to which they aredescribed, unless expressly specified otherwise.

Though an embodiment may be disclosed as including several features,other embodiments of the invention may include fewer than all suchfeatures. Thus, for example, a claim may be directed to less than theentire set of features in a disclosed embodiment, and such claim wouldnot include features beyond those features that the claim expresslyrecites.

No embodiment of method steps or product elements described in thepresent application constitutes the invention claimed herein, or isessential to the invention claimed herein, or is coextensive with theinvention claimed herein, except where it is either expressly stated tobe so in this specification or expressly recited in a claim.

The preambles of the claims that follow recite purposes, benefits andpossible uses of the claimed invention only and do not limit the claimedinvention.

The present disclosure is not a literal description of all embodimentsof the invention(s). Also, the present disclosure is not a listing offeatures of the invention(s) which must be present in all embodiments.

All disclosed embodiment are not necessarily covered by the claims (evenincluding all pending, amended, issued and canceled claims). Inaddition, an embodiment may be (but need not necessarily be) covered byseveral claims. Accordingly, where a claim (regardless of whetherpending, amended, issued or canceled) is directed to a particularembodiment, such is not evidence that the scope of other claims do notalso cover that embodiment.

Devices that are described as in communication with each other need notbe in continuous communication with each other, unless expresslyspecified otherwise. On the contrary, such devices need only transmit toeach other as necessary or desirable, and may actually refrain fromexchanging data most of the time. For example, a machine incommunication with another machine via the Internet may not transmitdata to the other machine for long period of time (e.g. weeks at atime). In addition, devices that are in communication with each othermay communicate directly or indirectly through one or moreintermediaries.

A description of an embodiment with several components or features doesnot imply that all or even any of such components/features are required.On the contrary, a variety of optional components are described toillustrate the wide variety of possible embodiments of the presentinvention(s). Unless otherwise specified explicitly, nocomponent/feature is essential or required.

Although process steps, algorithms or the like may be described orclaimed in a particular sequential order, such processes may beconfigured to work in different orders. In other words, any sequence ororder of steps that may be explicitly described or claimed does notnecessarily indicate a requirement that the steps be performed in thatorder. The steps of processes described herein may be performed in anyorder possible. Further, some steps may be performed simultaneouslydespite being described or implied as occurring non-simultaneously(e.g., because one step is described after the other step). Moreover,the illustration of a process by its depiction in a drawing does notimply that the illustrated process is exclusive of other variations andmodifications thereto, does not imply that the illustrated process orany of its steps are necessary to the invention(s), and does not implythat the illustrated process is preferred.

Although a process may be described as including a plurality of steps,that does not imply that all or any of the steps are preferred,essential or required. Various other embodiments within the scope of thedescribed invention(s) include other processes that omit some or all ofthe described steps. Unless otherwise specified explicitly, no step isessential or required.

Although a process may be described singly or without reference to otherproducts or methods, in an embodiment the process may interact withother products or methods. For example, such interaction may includelinking one business model to another business model. Such interactionmay be provided to enhance the flexibility or desirability of theprocess.

Although a product may be described as including a plurality ofcomponents, aspects, qualities, characteristics and/or features, thatdoes not indicate that any or all of the plurality are preferred,essential or required. Various other embodiments within the scope of thedescribed invention(s) include other products that omit some or all ofthe described plurality.

An enumerated list of items (which may or may not be numbered) does notimply that any or all of the items are mutually exclusive, unlessexpressly specified otherwise. Likewise, an enumerated list of items(which may or may not be numbered) does not imply that any or all of theitems are comprehensive of any category, unless expressly specifiedotherwise. For example, the enumerated list “a computer, a laptop, aPDA” does not imply that any or all of the three items of that list aremutually exclusive and does not imply that any or all of the three itemsof that list are comprehensive of any category.

An enumerated list of items (which may or may not be numbered) does notimply that any or all of the items are equivalent to each other orreadily substituted for each other.

All embodiments are illustrative, and do not imply that the invention orany embodiments were made or performed, as the case may be.

V. Computing

It will be readily apparent to one of ordinary skill in the art that thevarious processes described herein may be implemented by, e.g.,appropriately programmed general purpose computers, special purposecomputers and computing devices. Typically a processor (e.g., one ormore microprocessors, one or more microcontrollers, one or more digitalsignal processors) will receive instructions (e.g., from a memory orlike device), and execute those instructions, thereby performing one ormore processes defined by those instructions. Instructions may beembodied in, e.g., one or more computer programs, one or more scripts.

A “processor” means one or more microprocessors, central processingunits (CPUs), computing devices, microcontrollers, digital signalprocessors, or like devices or any combination thereof, regardless ofthe architecture (e.g., chip-level multiprocessing/multi-core, RISC,CISC, Microprocessor without Interlocked Pipeline Stages, pipeliningconfiguration, simultaneous multithreading).

Thus a description of a process is likewise a description of anapparatus for performing the process. The apparatus that performs theprocess can include, e.g., a processor and those input devices andoutput devices that are appropriate to perform the process.

Further, programs that implement such methods (as well as other types ofdata) may be stored and transmitted using a variety of media (e.g.,computer readable media) in a number of manners. In some embodiments,hard-wired circuitry or custom hardware may be used in place of, or incombination with, some or all of the software instructions that canimplement the processes of various embodiments. Thus, variouscombinations of hardware and software may be used instead of softwareonly.

The term “computer-readable medium” refers to any medium, a plurality ofthe same, or a combination of different media, that participate inproviding data (e.g., instructions, data structures) which may be readby a computer, a processor or a like device. Such a medium may take manyforms, including but not limited to, non-volatile media, volatile media,and transmission media. Non-volatile media include, for example, opticalor magnetic disks and other persistent memory. Volatile media includedynamic random access memory (DRAM), which typically constitutes themain memory. Transmission media include coaxial cables, copper wire andfiber optics, including the wires that comprise a system bus coupled tothe processor. Transmission media may include or convey acoustic waves,light waves and electromagnetic emissions, such as those generatedduring radio frequency (RF) and infrared (IR) data communications.Common forms of computer-readable media include, for example, a floppydisk, a flexible disk, hard disk, magnetic tape, any other magneticmedium, a CD-ROM, DVD, any other optical medium, punch cards, papertape, any other physical medium with patterns of holes, a RAM, a PROM,an EPROM, a FLASH-EEPROM, any other memory chip or cartridge, a carrierwave as described hereinafter, or any other medium from which a computercan read.

Various forms of computer readable media may be involved in carryingdata (e.g. sequences of instructions) to a processor. For example, datamay be (i) delivered from RAM to a processor; (ii) carried over awireless transmission medium; (iii) formatted and/or transmittedaccording to numerous formats, standards or protocols, such as Ethernet(or IEEE 802.3), SAP, ATP, Bluetooth□, and TCP/IP, TDMA, CDMA, and 3G;and/or (iv) encrypted to ensure privacy or prevent fraud in any of avariety of ways well known in the art.

Thus a description of a process is likewise a description of acomputer-readable medium storing a program for performing the process.The computer-readable medium can store (in any appropriate format) thoseprogram elements which are appropriate to perform the method.

Just as the description of various steps in a process does not indicatethat all the described steps are required, embodiments of an apparatusinclude a computer/computing device operable to perform some (but notnecessarily all) of the described process.

Likewise, just as the description of various steps in a process does notindicate that all the described steps are required, embodiments of acomputer-readable medium storing a program or data structure include acomputer-readable medium storing a program that, when executed, cancause a processor to perform some (but not necessarily all) of thedescribed process.

Where databases are described, it will be understood by one of ordinaryskill in the art that (i) alternative database structures to thosedescribed may be readily employed, and (ii) other memory structuresbesides databases may be readily employed. Any illustrations ordescriptions of any sample databases presented herein are illustrativearrangements for stored representations of information. Any number ofother arrangements may be employed besides those suggested by, e.g.,tables illustrated in drawings or elsewhere. Similarly, any illustratedentries of the databases represent exemplary information only; one ofordinary skill in the art will understand that the number and content ofthe entries can be different from those described herein. Further,despite any depiction of the databases as tables, other formats(including relational databases, object-based models and/or distributeddatabases) could be used to store and manipulate the data typesdescribed herein. Likewise, object methods or behaviors of a databasecan be used to implement various processes, such as the describedherein. In addition, the databases may, in a known manner, be storedlocally or remotely from a device which accesses data in such adatabase.

Various embodiments can be configured to work in a network environmentincluding a computer that is in communication (e.g., via acommunications network) with one or more devices. The computer maycommunicate with the devices directly or indirectly, via any wired orwireless medium (e.g. the Internet, LAN, WAN or Ethernet, Token Ring, atelephone line, a cable line, a radio channel, an optical communicationsline, commercial on-line service providers, bulletin board systems, asatellite communications link, a combination of any of the above). Eachof the devices may themselves comprise computers or other computingdevices, such as those based on the Intel® Pentium® or Centrino™processor, that are adapted to communicate with the computer. Any numberand type of devices may be in communication with the computer.

In an embodiment, a server computer or centralized authority may not benecessary or desirable. For example, the present invention may, in anembodiment, be practiced on one or more devices without a centralauthority. In such an embodiment, any functions described herein asperformed by the server computer or data described as stored on theserver computer may instead be performed by or stored on one or moresuch devices.

Where a process is described, in an embodiment the process may operatewithout any user intervention. In another embodiment, the processincludes some human intervention (e.g., a step is performed by or withthe assistance of a human).

VI. Continuing Applications

The present disclosure provides, to one of ordinary skill in the art, anenabling description of several embodiments and/or inventions. Some ofthese embodiments and/or inventions may not be claimed in the presentapplication, but may nevertheless be claimed in one or more continuingapplications that claim the benefit of priority of the presentapplication.

Applicants intend to file additional applications to pursue patents forsubject matter that has been disclosed and enabled but not claimed inthe present application.

VII. 35 U.S.C. §112, Paragraph 6

In a claim, a limitation of the claim which includes the phrase “meansfor” or the phrase “step for” means that 35 U.S.C. §112, paragraph 6,applies to that limitation.

In a claim, a limitation of the claim which does not include the phrase“means for” or the phrase “step for” means that 35 U.S.C. §112,paragraph 6 does not apply to that limitation, regardless of whetherthat limitation recites a function without recitation of structure,material or acts for performing that function. For example, in a claim,the mere use of the phrase “step of” or the phrase “steps of” inreferring to one or more steps of the claim or of another claim does notmean that 35 U.S.C. §112, paragraph 6, applies to that step(s).

With respect to a means or a step for performing a specified function inaccordance with 35 U.S.C. §112, paragraph 6, the correspondingstructure, material or acts described in the specification, andequivalents thereof, may perform additional functions as well as thespecified function.

Computers, processors, computing devices and like products arestructures that can perform a wide variety of functions. Such productscan be operable to perform a specified function by executing one or moreprograms, such as a program stored in a memory device of that product orin a memory device which that product accesses. Unless expresslyspecified otherwise, such a program need not be based on any particularalgorithm, such as any particular algorithm that might be disclosed inthe present application. It is well known to one of ordinary skill inthe art that a specified function may be implemented via differentalgorithms, and any of a number of different algorithms would be a meredesign choice for carrying out the specified function.

Therefore, with respect to a means or a step for performing a specifiedfunction in accordance with 35 U.S.C. §112, paragraph 6, structurecorresponding to a specified function includes any product programmed toperform the specified function. Such structure includes programmedproducts which perform the function, regardless of whether such productis programmed with (i) a disclosed algorithm for performing thefunction, (ii) an algorithm that is similar to a disclosed algorithm, or(iii) a different algorithm for performing the function.

Where there is recited a means for performing a function that is amethod, one structure for performing this method includes a computingdevice (e.g., a general purpose computer) that is programmed and/orconfigured with appropriate hardware to perform that function.

Also included is a computing device (e.g., a general purpose computer)that is programmed and/or configured with appropriate hardware toperform that function via other algorithms as would be understood by oneof ordinary skill in the art.

VIII. Disclaimer

Numerous references to a particular embodiment do not indicate adisclaimer or disavowal of additional, different embodiments, andsimilarly references to the description of embodiments which all includea particular feature do not indicate a disclaimer or disavowal ofembodiments which do not include that particular feature. A cleardisclaimer or disavowal in the present application shall be prefaced bythe phrase “does not include” or by the phrase “cannot perform”.

IX. Incorporation by Reference

Any patent, patent application or other document referred to herein isincorporated by reference into this patent application as part of thepresent disclosure, but only for purposes of written description andenablement in accordance with 35 U.S.C. §112, paragraph 1, and should inno way be used to limit, define, or otherwise construe any term of thepresent application, unless without such incorporation by reference, noordinary meaning would have been ascertainable by a person of ordinaryskill in the art. Such person of ordinary skill in the art need not havebeen in any way limited by any embodiments provided in the reference.

Any incorporation by reference does not, in and of itself, imply anyendorsement of, ratification of or acquiescence in any statements,opinions, arguments or characterizations contained in any incorporatedpatent, patent application or other document, unless explicitlyspecified otherwise in this patent application.

X. Prosecution History

In interpreting the present application (which includes the claims), oneof ordinary skill in the art shall refer to the prosecution history ofthe present application, but not to the prosecution history of any otherpatent or patent application, regardless of whether there are otherpatent applications that are considered related to the presentapplication, and regardless of whether there are other patentapplications that share a claim of priority with the presentapplication.

XI. Other Definitions

An “actual future state” is an actual state of a performance parameteras observed at a time after the performance parameter was observed to bein its initial state. It should be appreciated that if a performanceparameter does not change over a certain period of time, its initialstate at the beginning of that period may be the same as its actualfuture state at the end of the time period.

The term “automatically” refers to an action that occurs without humanintervention, e.g., an action that is caused by a computer processor inresponse to a predefined stimulus, condition, or set of conditions.

A “game time duration” means a period of time in a game, such as aninning, a quarter, a half, a tennis set, a period, and a round.

A “live event” means a game, election, or other event that takes placein real time and has a start time, a duration, and an end time. A liveevent such as a football game may not have a predetermined start timeand end time, e.g., because the game may start late or go into overtime.However, a live event for purposes of this application has an officiallyrecognized start time and end time. For instance, a football game mayofficially begin on the first kickoff and end when the time in thefourth quarter runs out. Similarly, an election may begin when the firstpolls open, and it may end when the last poll closes or when a candidateconcedes the election.

“Performance parameter” means a metric that measures a performance byone or more persons or things during a live event. A performanceparameter may comprise any variable related to a performance that canchange during the performance. A performance parameter of a sportingevent may comprise, for example: a score, a number of points, a numberof yards, a number of runs in an inning, a number of runs in a game, anumber of home runs, a number of base hits, a number of doubles, anumber of triples, a number of errors, a number of aces, a number ofgolf strokes by a player on a hole, a number of golf strokes by a playeron a plurality of holes, a number of three-pointers, and a number ofrebounds. A performance parameter of an election may comprise a numberof votes or electoral votes, number of counties won, number of precinctsreporting, etc.

The term “real time,” when used in connection with an event oroccurrence, means that the event or occurrence occurs at the same timeas or at substantially the same time as the occurrence of an associatedreference event. For instance, receiving and displaying video footage ofan event (such as a kickoff of a football game) in “real time” meansthat the footage is received and displayed at substantially the sametime as the event is taking place, as in a traditional “live broadcast”of a sporting event. It should be understood that there are often verysmall delays between an occurrence and a “real time” display of theoccurrence. For instance, it takes a very small amount of time toprocess a video signal, transmit it to a broadcast tower, transmit it toa receiver, decode the transmission, and display it at a display device.In spite of the slight delay, such a display is still in “real time.” Itmay also take a small amount of time for a reporter or announcer at thegame to provide a running audio or text commentary. Similarly, livecomedy shows often incorporate a two-second delay to enable sensors toedit any offensive material prior to broadcast.

In contrast, a longer delay between events might enable opportunisticgamblers to exploit the timing difference to their advantage. Forinstance, if a gaming operator allowed bets up until the “beginning” ofa boxing broadcast that lagged twenty seconds behind the real boxingmatch and a boxer scored a knockout after two seconds, then anopportunistic gambler at the match might exploit this delay by placing alarge bet on the winner before the bets closed. However, such a delayedbroadcast would not be considered in “real time” in the presentapplication. In the context of the gaming systems described herein, thedifference in time between a reference event and a corresponding “realtime” display or other event must be small enough that, for purposes ofan associated gaming system that intends to prevent cheating, it wouldbe impossible to place bets that would exploit the time difference tothe bettor's unfair advantage. Thus, text and audio reports orcommentary about an event (e.g., prepared by a reporter or announcer)may occur in “real time” if they meet this standard within the operationof the gaming system.

“State” means the condition of a person or thing (such as an event), ora characteristic of a person or thing, at a specific time or timeperiod. A state of a game at any given time may be defined (at least inpart) by such metrics as the score, the players on the field and theirrespective locations, time left in play, batting order, number of ballsand strikes for a given batter and pitcher, etc.

“State information” means information about the state of a person orthing (such as an event). State information may comprise a videobroadcast of an event, a running commentary of an event, a data feeddescribing occurrences of an event, etc.

“Initial state” means a state of a person, thing, or event before anoccurrence or specific type of occurrence. For instance, an initialstate of an at-bat may be “zero balls, zero strikes.” An “end” of aninitial state refers to the time just before the initial state changes,e.g., the time just before the first pitch in the at-bat.

“Possible future state” means one or more states that may occur at afuture time (e.g., at a future time of an event). For example, thepossible future states of an at-bat may be the possible outcomes of theat-bat: hit (single, double, triple, home run), walk, and strike-out.Possible future state may also be referred to as a possible outcome,e.g., associated with a performance parameter.

DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS

Traditional gambling systems enable users to bet on the outcome of agame, e.g., which team will win, and by how much. Gaming operators tryto determine accurate probabilities for each game outcome (e.g., win,loss, and point spread) so that they can offer competitive odds topotential bettors who may bet on each outcome. The probabilities (andodds) are typically determined prior to the start of the game based oninformation existing prior to the game, such as historical data relatedto each team, player, and coaching staff, ratings and opinions ofprofessionals such as sportswriters and other coaches, and other publicand proprietary information related to the game. For instance, somegaming operators use complicated proprietary computer algorithms todetermine odds based on pre-existing statistical information and otherinformation.

In effect, odds are a gaming operator's “price” to bettors for wageringon a specific outcome (wherein higher odds translate to a lower pricefor the bettor). When there are a plurality of gaming operators offeringodds on a particular outcome to a plurality of bettors, the gamingoperators compete with one another to offer a competitive price thatwill attract bettors who seek the highest payout for their bettingdollar. Thus, gaming operators may determine odds based in part on theodds offered by competing gaming operators. Betting behavior can alsoaffect odds. For instance, a high demand for bets that the Chicago Cubswill win their next game against the Phillies may drive up the effectiveprice for that bet. Accordingly, as in other competitive marketplaces,odds determinations often reflect a “market price” for each gameoutcome, as gaming operators adjust their odds based on the market. Theeffective market price can change over time as the betting marketchanges and new relevant information is disclosed, such as an injury ofa key Cubs pitcher a day before the game. Notably, amounts wagered bylosers on one side of the bet can be used to fund the payout to winnerson the other side of the bet. Thus, in large betting markets where thereare many bettors on each side of a bet, gaming operators may adjusttheir odds in an effort to balance the potential payouts on either sideof the bet.

However, odds determinations often do not reflect a consensus “marketprice,” e.g., when there are a limited number of market participants orthere is insufficient time for the market to assimilate new relevantinformation into a stable market price. For example, some gamingoperators allow users to bet on performance parameters within a game,such as whether a particular player will strike out in a particularat-bat in a baseball game. The betting market is typically openedmanually immediately prior to the in-game event, and the odds are oftendetermined manually “on the fly.” Even if another gaming operatoroffered a similar bet, the quick timing of such a bet may prevent gamingoperators and bettors from comparing the different odds offered. Inthese circumstances, the gaming operator attempts to offer odds withoutthe benefit of competitive betting market based entirely on theoperator's best assessment of the probabilities of the various outcomes.

Gaming operators can face many challenges in offering bets on thesetypes of in-game events as compared to typical “market price” bets onthe winner of a game. It takes time and labor to identify a potentialin-game betting market (e.g., a market for betting on the outcome of aspecific at-bat), determine accurate probabilities and odds for eachoutcome, offer the odds to bettors, take bets, determine an outcome, andthen pay the winners. Because traditional systems require many of theseactions to be performed manually “on the fly,” limited manpowereffectively limits the number and extent of in-game wager opportunitiesa gaming operator can offer. Bets on an in-game event often require acalculation of probabilities and odds in a very short time frame. It canbe more difficult to calculate an accurate probability of an in-gameoutcome when new relevant information becomes available during the game,such as an injury to a quarterback. Inaccurate odds can lead tounnecessarily high prices (and therefore fewer bettors) or unnecessarilylow prices (which translates to unnecessarily high payouts to winners).

According to various embodiments of the present invention, a system mayenable users to bet on in-game events, such as whether a particularbaseball player strikes out in a particular at-bat. The system mayautomatically receive general game information (e.g., team names, playerrosters, start time, etc.) from a data feed or other source. From thesame data source (or another source), the system may also automaticallyreceive a stream of real-time game information, such as elapsed time,batting line-up, runs scored, errors on a play, pitch information(strike, ball, foul), etc.

Odds for each event, such as a strike-out, may be calculated based on anodds database and algorithm stored on the system. The algorithm may useinformation from the real sport (such as a player's batting average),and may be updated based on in-game events. (E.g., if Barry Bondsstrikes out four times with the same pitcher, his odds of getting a hitoff that pitcher may decrease.)

As soon as a specific gambling event is completed (e.g., as soon asBarry Bonds finishes his at-bat by striking out or hitting a home run),the system settles the bets placed on that betting event. At the sametime (or another time), the system may open the betting for anotherevent (e.g., the next at-bat). In one embodiment, a human operatorclears the bets after each event. For example, the human gaming agentmay select “strike out” immediately after Barry Bonds strikes out. Thisoperation may cause the system to immediately settle all the bets on thepresent Barry Bonds at-bat and also open bets for the next betting event(e.g., the outcome of the next batter's at-bat). In other embodiments,the system may use automated information (e.g., a data feed) todetermine event outcomes (like a strike-out) in real time. In someembodiments, human gaming agents may assist with error correction toensure that the system identifies correct outcomes and resolves all betsproperly.

Users may place bets and otherwise interact with the system and otherusers via an interface such as a gaming table or mobile touch-screengaming device, which may be configured to display a live TV feed of anevent such as a baseball game with an optional touch-sensitive bettinginterface overlay. In one embodiment, when Barry Bonds steps up to theplate, a user may touch the image of Barry Bonds (or other image oricon) to trigger the betting interface overlay that enables the user toselect and place a specific bet concerning Barry's at-bat. To bet thatBarry will get a single, the user may touch an image of first base (orprovide another appropriate input).

Various embodiments of the system may enable gambling on many differenttypes of outcomes within a single game or other event, such as whether aparticular runner steals a particular base, the number of runs scored inan inning, whether a pitcher throws a ball or strike on a given pitch,etc. The system may open and close each betting event based on the startand finish time of that particular event. The system can also be appliedto a variety of sports as well as other events, such as elections (e.g.,whether Barack Obama will win New Hampshire in the upcoming 2008presidential election). It should be appreciated that variousembodiments of the invention may manage many different betting marketsat simultaneous or overlapping times. Each betting market may be opened,closed, and resolved based on the terms of that specific betting market,independently of other betting markets.

Thus, various embodiments of the invention may comprise a system thatmonitors real game events in real-time in order to accomplish thefollowing, for example:

(1) identify a specific in-game event (e.g., an at-bat) and the possibleoutcomes of the event (e.g., base hit or strike-out), e.g., based onstreaming game information received in real time;

(2) determine probabilities and odds for the potential outcomes;

(3) create a market for placing wagers on the in-game event (such as awager for a particular at-bat), and open the market so that players canplace bets;

(4) identify the outcome in the real game (e.g., strike-out);

(5) settle the bets based on the outcome (e.g., pay any winners); and

(6) identify additional events and possible outcomes, and open bettingmarkets for those events (e.g., the next at-bat). Of course, the timingof various markets may overlap; e.g., a bet on a specific at-bat mayoverlap in time with a bet on the number of runs in an inning.

In accordance with at least one exemplary embodiment, a stream of stateinformation of an event such as a live sporting event is received inreal time. A computer processor determines an initial state and aplurality of possible future states for each of a plurality ofperformance parameters of the event based on the state information. Aprobability of occurrence is calculated for at least one of theplurality of possible future states for each of the performanceparameters based on historical data related to each performanceparameter. The plurality of possible future states may be mutuallyexclusive from one another. During an initial state of the firstperformance parameter, a signal operative to open a first market forbetting on the at least one of the plurality of possible future statesis transmitted. The first market incorporates odds based on thecalculated probability of occurrence. After transmitting the signaloperative to open the first market, an end of the initial state isdetermined. After transmitting the signal operative to open the firstmarket and before the end of the initial state, a signal operative toclose the first market is transmitted. After transmitting the signaloperative to close the first market, an outcome of the first performanceparameter based on the received stream of state information isdetermined. A signal operative to resolve one or more payouts of thefirst market is transmitted. The signal indicates the outcome of thefirst performance parameter. Based on the outcome of the firstperformance parameter, a signal operative to update probabilities for aplurality of possible future states for a plurality of second bettingmarkets is transmitted. In another embodiment, a processor capable ofperforming these actions is provided. The processor is comprised in anapparatus comprising a processor and a memory, in which the memorystores instructions which, when executed by the processor, direct theprocessor to perform the steps.

According to another exemplary embodiment, various systems and methodsare provided for creating betting markets. The system may comprise atleast one processor and at least one memory that stores instructionswhich, when executed, direct the processor to perform one or more steps.State information of a live event may be received in real time. The liveevent may comprise a sporting event played by human players according topredetermined rules that are used to determine at least one winner ofthe sporting event. An initial state and a plurality of possible futurestates of a performance parameter of the live event may be determinedbased on the state information. A first betting market for betting on atleast one of the plurality of possible future states may be created. Theact of creating a first betting market may comprise (1) determining bythe processor probabilities for the plurality of possible future states,and (2) based at least in part on the probabilities, determining by theprocessor odds for betting on at least one of the plurality of possiblefuture states. After creating the first betting market, a first betcomprising a selection of one of the plurality of possible future statesmay be received from a first of a plurality of users. After receivingthe first bet, the first betting market may be closed prior to an endtime of the initial state. An instruction signal to close the firstbetting market may be transmitted from the processor. An actual futurestate of the performance parameter may be determined. The processor maydetermine that the possible future state selected by the first user isthe actual future state. A payout may be paid to the first user based onthe first bet and the act of determining that the possible future stateselected by the first user is the actual future state. The sportingevent may occur during an event time duration such that the sportingevent begins at the beginning of the event time duration and ends at theend of the event time duration. The sporting event may comprise aplurality of portions of the event occurring during sequential portionsof the event time duration, in which a plurality of possible futurestates comprises a possible future state occurring at the end of one ofthe sequential time periods, and in which at least one betting market iscreated for each of the sequential time periods.

FIG. 1. Exemplary System for Offering and Managing Wagers

Some embodiments of the present invention provide systems and methodsfor arranging and/or displaying output elements at a network site.

Server 2 may comprise one or more processors, computers, computersystems, computer networks, and or computer databases. Server 2 maycomprise modules 18-64. Server 2 may also comprise one or moredatabases, such as databases 80. Server 2 may communicate with users 10.For instance, server 2 may communicate with a user 10 computer, such asa browser of a user computer, e.g., over the internet.

Modules 18-48 may comprise one or more processors, computers, computersystems, and/or computer networks.

Databases 80 may comprise one or more processors, computers, computersystems, computer networks, and/or computer databases configured tostore information. Each of databases 80 may communicate with server 2and modules 18-64. For instance, server 2 and modules 18-48 may storeinformation in databases 80 and may also use information stored indatabases 80.

FIG. 1A depicts a system 100 for offering and managing wagers.

The system 100 may comprise one or more servers 2 coupled to one or moredatabases 80, one or more data providers 8 a-8 n, one or more end users10 a-10 n, and one or more gaming agents 12. The data providers 8 a-8 n,users 10, gaming agents 12, and server 2 may each communicate with eachother. Users 10 may also communicate with other users 10, e.g., topropose a wager against another user 10.

Users 10 a-10 n may comprise one or more persons who receive wageropportunities, propose wagers, and/or make wagers via agents 12 and/orserver 2. Users 10 may provide or receive information related to anevent or one or more wagers associated therewith. For instance, a user10 may comprise a gambler who receives information about an event, suchas real-time information about a sporting event. Users 10 may interactwith gaming agents 12, server 2, and/or other users 10 to create andplace wagers (and to receive offers to place a wager) regarding one ormore performance parameters associated with an event, such as the numberof runs scored in an inning of a baseball game. As used in thisapplication, users 10 a-10 n may also refer to a user's interface toother system 100 components (like server 2), such as a user's PDA orcomputer or a program running on a user's computer such as a computerweb browser like Internet Explorer™, which may communicate with dataproviders 8, gaming agents 12, and/or server 2.

Data provider(s) 8 may comprise any person, processor, informationservice, or other entity that publishes or otherwise providesinformation concerning an event or performance parameter to server 2,users 10, and/or gaming agents 12. For example, a data provider 8 maycomprise a data feed, sports announcer, event secretary orrecord-keeper, data service, website, or other source of informationrelevant to an in-game event. The information may comprise currentinformation about an event or sport, including but not limited toinformation about: one or more players, coaches, a team roster, currentweather conditions, and occurrences in the event (such as the outcome ofa specific at-bat). The data may also comprise historical informationabout people or other entities associated with an event, and any otherinformation that is related to an event. In some embodiments, the datamay include information that may be relevant to a probability of anoutcome of a performance parameter within the event. In someembodiments, the data may include information that may be of interest toa user 10 watching the event.

Data provider 8 may provide event and/or wager-related information inreal time, as information first becomes available to the general public,or at another time after an event. Data provider 8 may provide suchinformation in any one or more of a variety of forms and means such asvideo (e.g., a sporting event broadcast), audio (radio broadcast), text(e.g., the words of a radio broadcast in text form), or other data thatconveys information concerning the event. Data may be provided at avariety of different timings. In some embodiments, data may be providedin periodically, continuously, or continually, e.g., via a data feed(e.g., a stream of data that includes real time updates of eventinformation, such as a running commentary of a game in text or audioformat). In some embodiments, data may be provided after an event.

In some embodiments, data provider 8 may provide to server 2 (and/oragents 12 and/or users 10) a video broadcast of an event comprising aplurality of different camera angles. Server 2, agents 12, and/or users10 may then select among the different camera angles for viewing. Forinstance, a user 10 may select to view three different camera angles ofa football game—one focusing on a quarterback, one from behind thedefense, and one a top-down view—from among ten different camera angles,including one camera filming the commentators. Data provider 8 may alsoprovide processed data, such as video simulations of an event (e.g., amovement of “X's” and “O's” representing to show the movement ofoffensive and defensive players of a football game during a particularplay).

Gaming agents 12 may comprise one or more persons who process,facilitate, manage, provide, update, or otherwise interact withinformation associated with an event or one or more wagers associatedwith the event. For example, gaming agents 12 may comprise one or morecroupiers, dealers, casino employees, server 2 administrators, or otherpersonnel.

The server 2 may comprise a computer, server, hub, central processor, orother entity in a network, or other processor. The server 2 may compriseinput and output devices for communicating with other various system 100elements.

In some embodiments, the server 2 may be comprised in an end user'scomputer 10, e.g., as a toolbar in a user's web browser or anotherprogram running on the user's computer.

The server 2 may comprise a plurality of modules, such as module 18.Each module may comprise a processor as well as input and output devicesfor communicating with other modules, databases, and other systemelements.

A database 80 may be coupled to the server 2. The database 80 maycomprise a plurality of databases as described below. Databases 80 maystore information about users, elements, and other information.

The modules may function separately or in various combinations. Whilethe modules are shown within a single server, the modules may alsooperate among several servers. The modules may communicate with aplurality of databases, which may also function collectively orseparately.

The modules of server 2 may store, access and otherwise interact withvarious sources of data, including external data, databases and otherinputs.

Probability Module 18 may determine a probability of occurrence for oneor more future states of a performance parameter. Probability module 18may determine a probability of occurrence based on performanceinformation, such as information about a team or player's historicalperformance prior to the event. For instance, probabilities may bedetermined based on factors such as a player's performance in at leastone of the following performance categories: batting average, pointsscored, yards run, number of carries, runs batted in (RBIs), basesstolen, home runs, pass completion percentage, on base percentage, totalbases per at bat, number of errors, number of aces, double faultpercentage, free throw percentage, number of rebounds, handicap, numberof golf strokes, and a number of strike-outs. Probabilities may also bedetermined based on current performance information, such as informationabout a player's performance during the live event.

Probability module 18 may also update one or more probabilities based oninformation that becomes available during an event. In some embodiments,the information may be updated in real time or substantially real time.For instance, a probability associated with a particular outcome of aperformance parameter (such as the outcome of an at-bat) may bedetermined based on information relevant to the parameter existing priorto the event (e.g., a batter's historical batting average prior to abaseball game) and then updated based on a information relevant to theparameter that occurs during the live event (e.g., a batter's battingperformance of a particular at-bat during the game). Probability module18 may update probabilities associated with a number of differentperformance parameters and outcomes based on current game information.

Probabilities for various possible outcomes (and the corresponding oddsof those outcomes) may be updated in real time. Accordingly, a singleoccurrence during an event (such as an injury to a quarterback) maytrigger a change in the odds for a number of existing betting marketoutcomes, such as the number of passing yards, running yards, and pointsfor that quarterback; the team's chances of winning; the number ofpoints in any subsequent quarters; the number of total interceptions inthe game; etc. In this sense, important occurrences in an event can havea “ripple effect” that affects one or more betting markets.

Probability module 18 may use algorithms that enable quick calculationand modification of probabilities of outcomes (and accordingly thecalculation of their corresponding odds).

Odds module 20 may determine odds, e.g., based on probabilitiesdetermined by probability module 18. Odds module 20 may adjust odds overtime. Accordingly, the odds for a given bet may change during the“betting window” (i.e., the time between the opening and the closing ofa betting market wherein bettors may bet on a given outcome). Oddsmodule 20 may determine or adjust odds based on various factors, such asthe number and amount of bets on a particular outcome of set ofoutcomes; a “cut”, percentage, or other fee to be paid to another partysuch as a casino or “the house;” other “mark-ups”; the market for aparticular bet; and other factors. For example, odds may be adjusted ina similar manner and for similar reasons that odds are adjusted overtime for a particular bet at a popular Las Vegas casino on a specificteam to win the Super Bowl. For example, odds may be calculated andadjusted based on statistical information determined. For example, oddsmay be determined, e.g., by one or more elements of the system (oroutside parties), based on historical data and current information, suchas current weather information (e.g., whether it is raining or snowing,the temperature at the site of or in the vicinity of a particularsporting event that is the subject of the particular wager for whichodds are being determined), prior performance information about a user(e.g., by determining odds for a particular at-bat based on a player'sbatting average, e.g., against a certain pitcher, to determine the oddsthat the player will hit a single (or double, triple, etc.) against thatpitcher), and other information described herein that may be relevant toa determination of odds.

Amounts wagered on a losing bet can be used to pay payouts to a winningbet. Accordingly, in some embodiments, odds module 20 may adjust oddsfor one outcome based on the amount wagered on the outcome to ensurethat payouts for that outcome can be satisfied if it becomes the winningoutcome. Accordingly, where there are only two possible outcomes (e.g.,win or lose), and there are many large bets on one outcome (win) and asmall number of small bets on the other (loss), then the odds may beadjusted for future bets (or prior bets) to try to minimize the exposureof payouts for a win outcome. Improved odds for a loss bet may attractmore bettors to bet on loss, which would help minimize the exposure tothe “win” payout.

In some embodiments, odds module 20 may determine odds, e.g.,periodically or continually, based at least in part on liability and/orhedge information. Liability information and hedge information maycomprise information about the potential payout amounts to one or moreusers in the event that one or more bettors wins a bet on a particularbetting event. Liability and/or hedge information may also compriseinformation about changes in odds, and how a change in odds for aparticular betting event may affect future betting (e.g., number ofbets, timing of bets, and betting amounts) for the event (e.g., aparticular outcome, such as a run occurring during a particular at-bat).In some embodiments, odds module 20 may determine odds or adjust odds tominimize the potential liabilities of the system should any particularbetting outcome take place (e.g., and the system must pay a payout tothe winners who bet on that outcome). For example, odds module 20 maydetermine, e.g., continuously or periodically determine (e.g., everysecond, two seconds, five seconds, ten seconds, minute, hour, day, etc.)an amount (e.g., a net amount) of exposure to a particular outcome. Theexposure may be a net potential liability of amounts owed to potentialwinners of a bet minus income received from losing betters on adifferent side of the winning bet. In other words, the exposure may bethe amount that the house will “lose” in the event of a particularoutcome.

Those of skill in the art will appreciate that if a large number ofusers bet large amounts on a first of two possible outcomes and fewusers bet small amounts on the second of the two possible outcomes, thenif the first possible outcome takes place, then the “house” will have alarge liability to pay out the winning users. The “house” may keep theamounts wagered on the second possible outcome (which did not occur, andso those who bet on that outcome would lose their bets), and so thehouse may therefore use some of those funds to pay the winners. Thesystem could use funds kept or received from those who bet on the secondoutcome to pay the winners who bet on the first outcome.

For example, in some embodiments, odds module 20 may move a “bettingline” based at least in part on the amount of betting liabilities onboth sides of the bet.

For example, odds module 20 may change the odds to make it lessfavorable to the better to bet on a particular outcome where there is agreater liability if that outcome takes place. For example, if the oddsmodule 20 determines that the system must pay out $10 million if thereare at least five runs in the sixth inning of a baseball game, but mustpay out $20 million if there are four or fewer runs in the sixth inning,then odds module 20 may change the odds so that future bets that therewill be four or fewer runs in the sixth inning will have worse payoutsthan before. Similarly, odds module 20 may also improve the odds forbetting that there will be at least five runs in the sixth inning. Inthis way, odds module 20 may modify odds to encourage bettors to selecta bet that would decrease the exposure of the system in terms of netpotential payouts on the particular bet.

In another example, if the odds module 20 determines that the systemmust pay out $10 million if the Pittsburgh Steelers beat theIndianapolis Colts in a current football game, but must pay out $20million if the Colts beat the Steelers, then odds module 20 may changethe odds so that future bets that the Colts will beat the Steelers willhave worse payouts than before. Similarly, odds module 20 may improvethe odds for betting that the Steelers will beat the Colts.

For example, odds module 20 may modify the expected payout for one ormore particular outcomes (e.g., on one side of a bet, or on both sidesof a two-sided bet) by 2%, e.g., one time or periodically every tenseconds (or other time increment) until the liabilities on all sides ofa bet are “evened out” such that the system's exposure (e.g., netexposure) to payouts for any particular outcome are below a thresholdamount. For example, odds module 20 may modify odds (e.g., by decreasingodds on one side of a bet and increasing odds on another side of a bet)until the system determines that the system will receive more money thanit will lose for every possible outcome. Accordingly, for example, indetermining odds for a particular bet, odds module 20 may determine oddsbased on historical data such as batting averages and weatherinformation, and then modify such odds periodically based on the“exposure” of the system to the winning payouts of any particularbetting outcome. The odds determined for the bet may be the modifiedodds.

In some embodiments, odds module 20 may change odds, a price, a fee, a“spread,” or other betting parameter to encourage or discourage aparticular bet on a particular outcome.

In some embodiments, odds module 20 may update odds (and/or prices,spreads, and other betting parameters) for a particular betting outcomeor betting event at one or more different times. In some embodiments,odds module 20 may update such information each time a new bet isreceived by the system, or after every 10 bets are received (or anothernumber), or after a predetermined amount of time (e.g., 10 seconds).

Updates of the odds, prices, spreads, and other parameters may bereflected in a user interface and the wager offers offered to users. Forinstance, users may be offered wagers at the updated odds, spreads, etc.

User communication module 22 may communicate with users 10. Usercommunication module 22 may output to users via a communication deviceand receive inputs from users via a communication device. Communicationdevices may include cell phones, PDAs, computers, GPS devices,touch-sensitive displays, video game consoles, video game input devicessuch as controllers, electronic displays at a casino table,touch-sensitive displays, mouse, keyboard, image-recognition devices,and other devices.

In some embodiments, users 10 may maintain an account with an entityassociated with a gaming server 2, and communication module 22 mayrequire users to log in before accessing the account. The account maystore and manage user bets in a manner similar to how an onlinebrokerage account manages investments.

User-User communication module 24 may enable users to communicate withone another, e.g., to suggest bets to one another. For instance,user-user communication module may comprise a communication system thatenables or facilitates enabling a user 10 a to communicate with anotheruser 10 b via phone, text messaging, email, wireless communication,wireless gaming device, or other devices and systems for communicating.In some embodiments, a user 10 may suggest a bet to another user (e.g.,one user may propose to bet on one outcome if another user bets on anoutcome contrary to that outcome, e.g., one user bets a win whileanother bets a loss), and user-user communication module may publish theproposed bet to one or more other users, e.g., by displaying a betproposal at a communication device such as a gaming table.

Data provider module 26 may communicate with one or more data providers8, e.g., to obtain information about an event. For instance, dataproviders 8 may provide information about an event to server 2 via adata feed.

State identification module 28 may identify or otherwise define a stateof an event. The state may comprise a particular status of a game, e.g.,the players on the field, the count of the pitch, the inning, and otherinformation.

State identification module 28 may also update the state of an eventbased on event information received from data providers 8. For instance,module 28 may receive event information such as a video stream of anevent or a text play-by-play of an event. State identification module 28may process the event information. For instance, state identificationmodule 28 may process video or other image information to determineinformation about the state of an event such as a game, e.g., thelocation of a football at the end of a play when a referee signals theend of the play, whether a football carrier crossed a first down marker,whether a player stepped out of bounds, whether a ball hit by a batterwas hit out of the park within the “fair” territory, whether a tennisball hits the net or lands in “out” territory, etc. Accordingly, stateidentification module may automatically determine information related toperformance parameters and outcomes, e.g., whether a batter was struckout or whether a quarterback threw an interception.

In some embodiments, state identification module 28 may reconcileidentified states with another source of information related to anevent. For instance, in some embodiments, a gaming agent 12 may interactwith state identification module 28 to define states, correct any errorsin automatically determined states, and provide additional eventinformation. For instance, a gaming agent may note that a flag wascalled on a play after state identification module 28 determines that atouchdown was scored during the play. In some embodiments, module 28 mayreconcile information determined about a state with an “official” sourceof state information. For instance, an official umpire who referees agame may be an “official” source of information, such that a call madeby a referee concerning whether a ball was a ball may be controllingregardless of whether module 28 determines that a ball crossed abatter's strike zone. Accordingly, module 28 may interact with theumpire to determine official “calls” in the game, and this informationmay be used to update the event's state. In some embodiments, refereesmay enter state information (such as “ball” or “strike”) on a devicethat communicates directly with module 28 so that module 28 may updatestate information accurately.

Information about states may be communicated to users 10 and/or agents12. It may also be used to determine initial states and possibleoutcomes of a performance parameter, and to determine or updateprobabilities associated with the outcomes.

In some embodiments, state identification module 28 may identify eventstates and state changes (such as betting outcomes) automatically. Forinstance, state identification module 28 may analyze one or more sourcesof data to automatically identify an event state, such as an outcome ofa betting event. For instance, state identification module 28 may use avariety of sources to determine and/or confirm that a tennis player hasscored a point, such as image processing software that analyzes a livevideo feed of the match; “play-by-play” information from a data feed;and a website that outputs the score of a game in substantiallyreal-time.

State identification module 28 may analyze a video feed of a live tennismatch to identify whether a tennis ball landed “in” or “out” on aplayer's side of the court. State identification module 28 may alsoreview “play-by-play” information from a data feed indicating that atennis point has been scored by the player.

In some embodiments, a human operator may determine the outcome of abetting event. For instance, the human operator may watch the live event(e.g., live in person or via live television broadcast). In someembodiments, a human operator may determine the outcome of a bettingevent and then cause the system to settle bets based on the determinedoutcome. In this way, the bettors will have immediate feedback.

Parameter creation module 30 may create and define performanceparameters or performance parameter-related data and metrics formeasuring a performance parameter at a given time (e.g., how many yardsa running back has gained so far in a given football game by the end ofthe third quarter). Parameter creation module 30 may also enable usersto specify a performance parameter. For instance, a user may specify aperformance parameter based on any variables of an event. While someperformance parameters, such as total yards of a running back in a givengame, are often tracked by many third parties, user-specifiedperformance parameters may be performance parameters that are nottypically tracked by traditional casinos. Some examples include: theaverage stride of a particular running back; the number of times a ballis passed during a particular possession of a basketball team; thenumber of times a tennis racquet touches the ground during a match; etc.

Parameter tracking module 32 may track a particular performanceparameter (e.g., number of points scored) throughout an event, e.g.,based on data received from data providers 8.

Betting market module 34 may create a betting market for a performanceparameter. For instance, betting market module 34 may identify aperformance parameter that can have a plurality of possible futurestates. Once the performance parameter and possible future states areidentified, betting market module 34 may enable users to place one ormore bets on the possible future states based on odds determined byprobability module 18. Betting market module 34 may open and close themarket based on state information.

For instance, betting market module 34 may open the market at or duringan initial state, and then close the market at the end of an initialstate. An initial state may comprise a time before a performanceparameter has changed to one or more possible future states. Forexample, module 34 may open a market for betting on a particular at-batwhen the batter is “on deck” (i.e., when the preceding batter iscurrently at bat). Module 34 may close the betting market before thefirst pitch to the particular batter. In some embodiments, module 34 maykeep the betting market open for a longer period, e.g., until a specificone of the possible future states is achieved. For instance, module 34may enable users to continue to bet on an at-bat during the at-bat untilthe batter walks, gets a hit, strikes (or fouls) out, or the at-batotherwise ends.

In some embodiments, probability module 18 and odds module 20 may updatethe probabilities and odds for the various outcomes as new stateinformation becomes available while the market is open. For instance, inan at-bat market that stays open during the at-bat, if the first twopitches are strikes, the probability that the batter will strike out mayincrease significantly, and odds for a strike-out (and the otherpossible outcomes) may be recalculated accordingly.

Market module 34 may also determine an actual future state and resolveany bets based on the actual future state. For instance, market modulemay determine that a batter struck out, and therefore calculate and paythe appropriate payout to bettors who bet on strike out, and notifybettors who bet on a home run that they lost the bet.

A gaming agent 12 may interact with market module 34 to verify an actualfuture state (e.g., to verify that a batter actually struck out). Forinstance, agent 12 may double check a determination of an actual stateby module 34 before bets are paid out.

Create-a-metric module 36 may enable users 10 to create a performanceparameter. For instance, a user 10 may create a performance parameter,and the server 2 may identify future possible states for the performanceparameter and odds associated with each possible state. Then the user 10may place a wager on one or more of the possible future states.

Database 80 may comprise a plurality of databases for storinginformation related to an event, one or more users 10, one or more dataproviders 8, one or more gaming agents 12, and one or more bettingmarkets. Probability Database may store probability information relatedto an event, such as information relating to the probability of a futureoccurrence.

Create-a-metric Database may store event and performance data (formultiple events), as well as categories of performance data. Informationin the database may be used to enable users to create a metric, e.g.,for wagering.

As shown in FIG. 2, a system 200 that accomplishes the same functions asthat of system 100 of FIG. 1 may comprise two different servers 2, i.e.,a front end server 2 a and a back end server 2 b. The front end server 2a may interact with users 10 and gaming agents 12 to provideevent-related information and receive bets. The back-end server 2 b maydetermine event states, performance parameters, and outcomes. In someembodiments, the back-end server 2 b may be ignorant of any bets orother interactions with users 10.

For example, as a back-end system, server 2 b may be configured toreceive a stream of state information of a live sporting event in realtime (or another time). The server 2 b may determining by a computerprocessor an initial state and a plurality of possible future states ofa first performance parameter of the live sporting event based on thestream of state information. After a beginning of the game and beforethe start of the event, the server 2 b may calculate a probability ofoccurrence for at least one of the plurality of possible future statesof the first performance parameter based on historical data related tothe first performance parameter, the plurality of possible future statesbeing mutually exclusive from one another. The server 2 b may transmit,during an initial state of the first performance parameter, a signaloperative to enable server 2 a to open a first market for betting on theat least one of the plurality of possible future states, the firstmarket comprising betting odds based on the calculated probability ofoccurrence. After transmitting the signal operative to open the firstmarket, server 2 b may determine an end of the initial state. Before theend of the initial state, server 2 b may transmit a signal operative toclose the first market. After transmitting the signal operative to closethe first market, server 2 b may determine an outcome of the firstperformance parameter based on the received stream of state information.The server 2 b may transmit a signal operative to resolve one or morepayouts of the first market, the signal indicative of the outcome of thefirst performance parameter.

In some embodiments, the act of calculating a probability of occurrencefor at least one of the plurality of possible future states may comprisecalculating a probability of occurrence for the at least one of theplurality of possible future states of the first performance parameterbased on prior historical data related to the first performanceparameter existing prior to a beginning of the live sporting event.

In some embodiments, the server 2 b may also determine currenthistorical data about the first performance parameter based on at leasta portion of the stream of state information received after a beginningof the live sporting event, wherein the current historical data does notexist prior to the beginning of the live sporting event. The act ofcalculating a probability of occurrence for the at least one of theplurality of possible future states may comprise calculating aprobability of occurrence for the at least one of the plurality ofpossible future states of the performance parameter based on the priorhistorical data and the current historical data.

In some embodiments, the server 2 b may determine current historicaldata about the first performance parameter based on at least a portionof the stream of state information received after a beginning of thelive sporting event, wherein the current historical data does not existprior to a beginning of the live sporting event. Server 2 b mayre-calculate the probability of occurrence for the at least one of theplurality of possible future states based on the current historicaldata. Server 2 b may transmit a signal operative to update the odds usedin the first market based on the re-calculated probability ofoccurrence.

In some embodiments, server 2 b may also re-calculate a probability ofoccurrence for at least one possible future state of a secondperformance parameter based on the current historical data. The server 2b may transmit a signal operative to update betting odds used in asecond market for betting on the second performance parameter based onthe re-calculated probability of occurrence for the at least onepossible future state of the second performance parameter.

In some embodiments, server 2 b may determine by a computer processor aninitial state and a plurality of possible future states of a secondperformance parameter of the live sporting event based on the stateinformation. Server 2 b may calculate a second probability of occurrencefor at least one of the plurality of possible future states of thesecond performance parameter based on historical data related to thesecond performance parameter. The plurality of possible future statesmay be mutually exclusive from one another. The server 2 b may transmit,during an initial state of the second performance parameter, a signaloperative to open a second market for betting on the at least one of theplurality of possible future states of the second performance parameter,the second market using odds based on the second probability ofoccurrence. After transmitting the signal operative to open the secondmarket, server 2 b may determine an end of the initial state of thesecond performance parameter. After transmitting the signal operative toopen the second market and before the end of the initial state of thesecond performance parameter, server 2 b may transmit a signal operativeto close the second market. After transmitting the signal operative toclose the second market, server 2 b may determine an outcome of thesecond performance parameter based on the received stream of stateinformation. Server 2 b may transmit a signal operative to resolve oneor more payouts of the second market, the signal indicative of theoutcome of the first performance parameter.

In some embodiments, server 2 b may also determine current historicaldata related to both the first and second performance parameters basedon at least a portion of the stream of state information received aftera beginning of the live sporting event. In some embodiments, theprobability of occurrence for the at least one of the plurality ofpossible future states of the first performance parameter and theprobability of occurrence for the at least one of the plurality ofpossible future states of the second performance parameter arecalculated based on the current historical data.

FIG. 3. Exemplary Method of In-Game Wagering.

It should be appreciated that the system of this invention may be usedto manage bets for any type of event having a plurality of possibleoutcomes, such as an election, a sporting event, or an event occurringwithin another event (such as an at-bat in a baseball game, or acompetition for the electoral votes of a particular state in a U.S.presidential election). For example, the system may be used to managebets in any of the following types of competitions, as well as any othercompetition or sport: a racquet sport (such as tennis, squash, orbadminton), baseball, softball, cricket, surfing, football, soccer,basketball, hockey, gymnastics, skating, golf, running, swimming,skiing, biking, rugby, polo, water polo, bowling, dancing, billiards,shooting, a track and field competition, horse racing, dog racing,automobile racing, motorcycle racing, boat racing, fishing, boxing, amartial art competition, a mixed martial arts competition (such asUltimate Fighting Championship), a casino game, a card game, chess, andfalconry.

In block 305, the system may receive pre-event information about anevent. For instance, the system may receive from a data feed informationabout two teams playing in a game, such as a team roster, battingline-up (baseball), starting offensive line (football), an injury reportfor any potentially injured players, a game start time, and otherinformation. The information may be downloaded or otherwise receivedfrom any source, such as a league or team website, press release, ESPN™,or other source of event information.

In block 310, the pre-event game information may be outputted to one ormore users, e.g., via radio or television broadcast or over theinternet. The game information, such as live video footage of a sportingevent, may be displayed to the user at a television or computer monitor,radio, mobile phone, or other output device. In some embodiments, theinformation may be displayed on a device capable of receiving userinputs, such as a touch-sensitive display device. The display device maybe operable to accept user inputs, e.g., by selecting from among variousbetting options on a touch-sensitive display.

In block 315, the system may receive information about the event duringthe event. For instance, the system may receive a data feed or a livebroadcast.

In block 320, game information may be output to one or more users, e.g.,via radio or television broadcast or over the internet. This informationmay be output to users 10 and agents 12. For instance, the gameinformation, such as live video footage of a sporting event, may bedisplayed to the user at a television or computer monitor, radio, mobilephone, or other output device. In some embodiments, the information maybe displayed on a device capable of receiving user inputs, such as atouch-sensitive display device. The display device may be operable toaccept user inputs, e.g., by selecting from among various bettingoptions on a touch-sensitive display.

In block 325, a user 10 may define a performance parameter. Theperformance parameter may be created based on performance categories,variables, metrics, and other event or performance information providedby the system.

For instance, a user 10 may define the performance parameter “length ofaverage running stride of Lebron James starting in the third quarter.”The system may track this performance parameter, e.g., by measuring eachrunning stride of Lebron James while he is on the court during the thirdquarter. The system may enable users to bet on this parameter. Forexample, the system may enable users to bet on whether his runningstride is more than five feet or less than five feet. At the end of thethird quarter, the system may calculate the average stride of LebronJames and resolve the bets accordingly.

In block 330, the system may determine state information relating to aperformance parameter (e.g., a user-created performance parameter or apre-defined performance parameter), e.g., based on information receivedabout the event. The state information may comprise any status orhistorical information about the event. For instance, based on areal-time data feed of a sporting event, the system may determinewhether a sporting event has begun, the score, time remaining, balls andstrikes of a specific batter, which players are currently on the field,at time 0 a specific sporting event has not started.

In block 335, the system may identify a plurality of possible futurestates of the event. The end states may be mutually exclusive, and theymay relate to a specific performance parameter or occurrence thathappens during the event.

In block 340, the system may identify one or more start times associatedwith a set of possible future states associated with the performanceparameter. For instance, a start time of an at-bat may coincide with anend time of a prior at-bat. In some embodiments, start times may triggerthe opening of a betting market.

In block 345, the system may determine statistics associated with anoutcome or type of outcome. For instance, the system may determinestatistics associated with one or more performance parameters associatedwith a particular team or player (or other event entity), such aswhether a particular player will get a single or a home run for aparticular at-bat.

In block 350, the system may determine probabilities and odds associatedwith one or more possible outcomes. In some embodiments, theprobabilities may be received or calculated from a database ofstatistical information or probabilities. The database may be maintainedby a third-party.

In some embodiments, the probabilities and odds may be calculated basedon pre-existing information, such as a database of baseball statisticsexisting prior to a baseball game, as well as current information suchas performance data of the baseball players during the baseball game.

The probabilities and odds may be updated as relevant event informationis received. For instance, the probability that a quarterback will throwthree touchdown passes in a particular game will decrease if thequarterback is injured.

In block 355, a user 10 may request information relevant to a bet, e.g.,from the system. For instance, the user 10 may request historicalinformation, such as information about a player or team's pastperformance (e.g., with respect to a particular performance parameterlike total yards) and/or current performance (e.g., performance duringthe current game). The user 10 may also request information about whatbets are available and the odds for each.

In some embodiments, a user 10 may request information by selecting aparticular player on a screen. For example, a user 10 may touch a videoimage of a pitcher to request information about the pitcher's pitchingrecord. In some embodiments, a user 10 may select to bet that a pitcherwill strike out a current batter by touching the image of the pitcher.

In block 360, the system may provide betting information. For example,the system may output a betting overlay at a user display device. Theoverlay may display betting options such as the various possibleoutcomes for which the user may wager, the odds for each, probabilitiesor statistics relating to the various outcomes, and any otherinformation that may be relevant to a user 10 bet.

In block 365, a user may select a bet. For instance, the user maynavigate a menu of betting options, e.g., on a touch-sensitive display,e.g., on a mobile phone.

In block 370, the user 10 may place a bet associated with theperformance parameter. For example, the user 10 may bet that aparticular batter will strike out.

In block 375 the system may close bets for a particular event or bettingmarket, e.g., after a start time for a particular in-game event. Forinstance, the system may close betting on a particular at-bat for BarryBonds before Bonds steps up to the plate to receive the first pitch, orafter Bonds steps up to the plate but before the pitcher begins to throwthe first pitch to Bonds.

In some embodiments, the system may close bets automatically, i.e.,without human intervention. In some embodiments, a human operator mayclose the bets. For instance, the human operator who is watching theevent (e.g., live in person, or via TV broadcast with minimal timedelay) may cause the system to close bets for a particular Bonds at-batat a moment immediately before the pitcher throws the first pitch (or atanother appropriate moment). In circumstances where the system does notreceive information about an occurrence (such as Bonds stepping up tothe plate) until after occurrence has taken place (e.g., due to 2-seconddelay in a television broadcast), a human operator may be in a betterposition to determine an optimal time for closing betting for an event(e.g., the last possible moment before the beginning of the event).

In some embodiments, the system may continue to allow bets on the event,but the betting options may change during the course of the event. Forinstance, the system may continuously or periodically update the oddsrelating to various outcomes based on current in-game information. Forinstance, the system may recalculate the odds of various at-bat outcomesafter each pitch. For instance, the system may determine that the oddsthat Bonds strikes out increase after each strike, and the odds that hewill get walked increase after each “ball.”

In block 380, the system may receive real time information about thestate of an event. The information may be received from any source ofcurrent event information, as discussed above. The real time event stateinformation may comprise real time historical information about theevent, such as information relating to the end result of an event (e.g.,strike out), information that might affect probability of an outcome ofan event (e.g., a mild injury to a quarterback), performance information(e.g., number of yards gained by a particular running back during aparticular play), game time elapsed and remaining, and other eventinformation.

In block 385, the system may identify an outcome of an event, such as anevent that is the subject of a bet. For instance, the system maydetermine an actual state among the possible future states. Forinstance, the system may determine that Barry Bonds struck out based ona source of event information.

The system may then resolve all bets related to the associated bettingmarket. For example, the system may issue an appropriate payout to anywinning betters and issue notifications to those who had losing bets.

In some embodiments, users 10 may keep a betting account that containsan amount for wagering. Users 10 may continue making bets until theaccount is depleted or otherwise unavailable for further bets.

It should be appreciated that the actions described in the above blocksare exemplary only, and need not be performed in the order presentedhere. Further, it is not necessary to accomplish all of the actionsdescribed in the blocks. Rather, any number of the blocks (e.g., four ofthe blocks or six of the blocks) may be accomplished, and in any order.

FIGS. 4A and 4B depict exemplary gaming tables 401 and 402 for use in atleast one embodiment of the methods and systems disclosed herein. FIGS.5A-5C depict exemplary interface screens for use in at least oneembodiment of the methods and systems disclosed herein. It should beunderstood that the tables 401 and 402 may also be interfaces, and theinterfaces 501-503 may also be tables. Accordingly, the general featuresof these tables 401, 402 and interfaces 501-503 may apply equally toeach other. Notably, tables 401 and 402 and interfaces 501-503 displayinformation to users 10 and enable users 10 to place bets.

The tables 401, 402 and interfaces 501-503 of FIGS. 4A-5C may be locatedin a casino, a user's house or workplace, a stadium or other locationassociated with an event such as a live sporting event, or anotherlocation. In some embodiments, the tables and interfaces may be physicalgaming tables that may facilitate making wagers associated with aspecific live event. Although the exemplary tables and interfacesdepicted in FIGS. 4A-5C are configured to facilitate wagers associatedwith a sporting event such as a baseball, cricket, or football game, itshould be understood that a gaming table of the present invention may beconfigured to facilitate bets associated with other sports and otherevents, such as elections. The gaming tables and interfaces mayfacilitate bets (e.g., for an event such as a baseball game or footballgame), e.g., in a manner similar to how a craps table at a casinofacilitates wagering on dice rolls by one or more users. In someembodiments, the tables and interfaces may comprise an electronicdisplay, such as a traditional computer monitor (e.g., a user's computermonitor). In some embodiments, the gaming tables and interfaces maycomprise a touch-sensitive display and/or any other input and/or outputdevices. For example, a craps table at a casino may be replaced by alarge, flat table that comprises a large touch-sensitive display.

It should be appreciated that the display may be configured to interactwith one or more persons in a variety of ways, e.g., via touch, sound,and other inputs and outputs. Users 10 and gaming agents 12 (such asdealers or croupiers of a casino) may provide inputs at the table by avariety of means. For instance, users 10 and gaming agents 12 mayinteract with the touch-sensitive displays 401, 402 and 501-503 bytouching selected portions of the display. The touch-sensitive displaymay recognize touch as well as other inputs, such as via mouse,keyboard, camera, etc. The display may detect motion (e.g., byprocessing images from a camera) and thereby identify instructions orother inputs from users 10 and gaming agents 12. For instance, thedisplay may detect hand signals that represent a certain type of bet,bet amount, or other instruction or update. In some embodiments, users10 may place bets by touching the display to select a specific bettingoutcome and wager amount. The user 10 may select particular portions ofthe display or images on the display to indicate betting selection,e.g., by selecting a particular player and/or a location on the playingfield to indicate a bet that a runner on first will get to third baseduring the next at-bat.

Referring to FIGS. 4A and 4B, the tables 401 and 402 may display statusand other information about a live event, e.g., to a user 10 or a groupof users 10. Information displayed on the gaming table may be updated,e.g., in real time. For a physical gaming table 401 similar to a crapstable, the table may be updated when a gaming agent 12 manually changesstatus information, e.g., by manually changing a score displayed on thetable. (However, the updated information may be transmitted to thegaming agent 12 automatically.) For an electronic display 401 or 402,such information may be updated or otherwise changed automatically.

A dealing or croupier area 420 may be used by gaming agents 12. Thecroupier area 420 may display information such as the current baseballinning (e.g., 5^(th) inning) and team logos indicating the teamscurrently playing (e.g., the Phillies and the Cubs). In someembodiments, the croupier area may show the probabilities and/or oddsthat each team will win the game. The probabilities and odds may changeover the course of the game based on game events, such as runs by eitherteam. For instance, the chances that the Cubs will win if the Cubs areleading by four at the end of the sixth inning.

A “most runs” area 410 may show information about betting marketsrelated to the number of runs by each team playing. An “inning errors”area 430 may show information about betting markets related to thenumber of errors made by either team during an inning “Base status”areas 440, 480 may indicate information about the status of a baserelated to one or more betting markets, such as who is on a particularbase, and whether the runner is advancing or has advanced. Runs area(e.g., area 450) may indicate information about betting markets relatedto the number of runs by a specific team.

For instance, areas 410, 430, 440, 450, 480 may display probabilitiesand odds offered for various bets, such as bets associated with how manyruns will be scored by a particular team. For example, most runs are 410may indicate that there is an 20% probability that the Cubs will scoremore runs than the Phillies in the next inning (or a current inning).Runs are 410 may also indicate that the payout odds are 3 to 1 forbetting that the Cubs will score the most runs (i.e., that a bet of $1will return $3 if the Cubs score the most runs that inning). As thenumber of runs by the Cubs and Phillies changes during the inning, theprobabilities and odds may change. For instance, if the Phillies do notscore any runs at the top of the inning and the Cubs have the basesloaded with no outs, the probability may change to 90% that the Cubswill score the most runs that inning (i.e., more than the Phillies zeroruns), and the odds may change to reflect this.

As shown in FIG. 4B, a gaming table 402 may also be configured forAmerican football or another sport. As shown on the table 402,designated areas of the table enable users to place bets on either theDallas Cowboys or the Green Bay Packers concerning which team will havethe most running yards or passing yards in a present quarter, andwhether a team currently on offense will get another first down before achange in possession. The table 402 also shows drive outcome statusinformation. The drive outcome areas of the table 402 may alternatively(or in addition) used to place bets on a specified outcome, such aswhether a particular team gets a field goal or touchdown.

In some embodiments, a gaming table or interface may comprise aplurality of values (or ranges of values) of a performance parameter,e.g., arranged in one or more rows, columns, grids, or otherarrangements. The values may comprise possible future values of theperformance parameter. For instance, the values may comprise two sets ofpossible scores as measured at the end of a current quarter of afootball game, one set of scores for each team. As in FIGS. 4A-4B, thegaming table may be configured to enable users 10 to place one or morebets associated with specific values. For instance, a user 10 may betthat by the end of the second quarter (or another time, such as the endof a game), the first team will have 7 points. Alternatively, or inaddition, the user may bet that the team will have between 3 and 10points. The user 10 may also bet that the other team will have 14 points(or between 10 and 17 points). In some embodiments, users may place abet that one team will have a certain number (or range) of bets andanother team will have another number (or range) of points, e.g., at aspecific point in the game.

In some embodiments where the table or interface comprises atouch-sensitive display, users 10 may select to bet on a particularvalue (or range) by touching the intended value or range. For instance,a user 10 may touch “7 points” in a first column to indicate a score fora first team, “14 points” in a second column to indicate a score for asecond team, select an amount for wager (e.g., by touching one or moreimages of one or more chips of varying colors and amounts), and thenconfirming the bet.

The gaming table may also display other information related to thevalues, such as probabilities and odds. The values and other informationmay be updated, e.g., in real time, e.g., based on current eventinformation. For instance, various possible values may be disabled forbetting purposes once the possible value becomes impossible. Forexample, once a team scores 14 points, an ending score of 7 (or anyscore or range from 0 to 13) becomes impossible, and these impossiblescores may be removed from the table. In some embodiments, scores orranges of scores may be arranged in ascending order in a column. As theactual score increases, impossible values may be removed from the top,the next highest values may move to the position of the removedscore(s), and new higher values may be added at the bottom.

FIGS. 5A-5C depict exemplary interface screens for use in at least oneembodiment of the methods and systems disclosed herein. In someembodiments, the interface screens may comprise a gaming table similarin form and/or function to that described for FIG. 4, e.g., atouch-sensitive display, computer display, or physical table at acasino. The interface 501 in FIG. 5A may display information related toan event such as a game. The interface 501 may also display informationrelated to one or more betting markets associated with the event, suchas a betting market implemented using the interface 501.

Interface 501 comprises a video 510. The video 510 may comprise actualvideo footage of an event such as a baseball or (English) cricket game,such as a pitch from a pitcher to a batter. The video may comprise avideo broadcast of the event received in real time. Alternatively, thevideo 510 may comprise a simulated animation of an event such as apitch. In some embodiments, a user 10 may select different simulated (orreal) camera angles of the event, rewind and replay the video.

In some embodiments, interface 501 may comprise multiple spaces forvideo 510, e.g., for viewing several different video feedssimultaneously, either for the same event or different events. Forinstance, the multiple videos may be tracking different players in agolf tournament, or different golf holes that are being playedsimultaneously. In some embodiments, the multiple videos may track twodifferent games (e.g., two different football games) that are playing atthe same time.

In some embodiments, the video 501 may comprise video of an event aswell as inputs (such as buttons, e.g., touch-sensitive images ofbuttons) that enable agents 12 and/or users 10 to provide informationabout the event. For example, an agent 12 (or user 10) may select abutton next to a pitcher just before a first pitch in order to informthe server 2 (or confirm to the server 2) that an at-bat is about tobegin. An agent 12 viewing several different videos of different eventsmay provide information to server 2 and users 10 about betting markets(e.g., related to the state of an initial state, or the time an initialstate begins or ends, or a possible or actual future state).

Score board 515 may display status information related to the eventand/or status information related to one or more betting marketsassociated with the event, such as bets made via the interface 501. Forexample, score board 515 may display game time information such as timeremaining or the number of the inning, score information such as thescore of a game or a particular inning, and other information about oneor more game performance parameters. Ball-by-ball scoreboard 520 maydisplay a score for each ball played, e.g., in a game of cricket.

Umpire animation 525 may comprise information about an action ordecision of an umpire or referee, e.g., with respect to a particularfoul, penalty, or other event. For example, umpire animation 525 maydisplay an image or video animation of a referee making a particularcall or taking a particular action. Exemplary referee images are shownin FIG. 6.

The bottom right area 530 shows betting options related to the minimumor maximum player/banker and tie/pairs. Betting chips 535 may be used toplace bets and may be redeemable for a predetermined amount of cash(e.g., one red chip is redeemable for five dollars). Chips 535 may bepurchased from a croupier or other gaming agent 12 from chip reservoir550.

In some embodiments, users 10 and gaming agents 12 may interact with thetables and interfaces as they would with a traditional casino table(like a craps table), e.g., by manually placing real game chips 535 tosignify a particular bet and amount. In some embodiments, users 10 andgaming agents 12 may place bets electronically from a user account. Insome embodiments, users 10 may place bets using “electronic chips”comprising a displayed image of one or more chips corresponding to theirequivalent counterparts in a real casino.

Bet status information 540 may indicate whether a bet is active, pushed,or paid. One or more cards 545 may be used, either separately or inconjunction with gambling associated with an in-game event. Game historychart 555 may display numerical (e.g., score) or other information abouta past or current game associated with the game for which betting isenabled at the interface.

FIGS. 5B and 5C depict additional exemplary interface screens, which maybe used in a manner similar to that described for FIG. 5A. As shown inFIG. 5B, buttons 580 may be selected to view or change a games menu, auser account, applicable rules, and service. Interface option buttons590 enable users to select sounds, voiceovers (e.g., as opposed to textinformation).

FIG. 6 depicts exemplary referee animation images for use in at leastone embodiment of the methods and systems disclosed herein, e.g., withrespect to the English sporting game cricket. From left to right, theimages in FIG. 6 may refer to (1) a referee's normal stance (no penaltyor foul); (2) no ball signal; (3) four runs signal; (4) wide ballsignal; (5) six runs signal; and (6) out signal.

FIG. 7 depicts an exemplary interface screen 700 for use in at least oneembodiment of the methods and systems disclosed herein. Screen 700 showsan interface for a game that integrates events from a live event. Here,the game may be of a game type similar to bingo, wherein users 10 win bymatching in-game events (such as a strike-out, ball, strike, etc.) withcorresponding panels from the board (that indicate strike-out, ball,strike, etc.). Winning conditions 710 may define a condition for winningthe game, such as the need to obtain 12 panels in a row. Betting options720 enable users 10 to place bets on a variety of outcomes of an at-batsuch as ball, strike, hit (or other contact with ball), or otheroutcome.

In some embodiments, a user 10 may win different amounts by matchinglonger sequences of panels based on batters' performance. The user 10may select a sequence of pitches that would occur at the start of thenext defined period. This period might be the next at bat, half innings,inning, etc. In some embodiments, the period may be chosen based on howquickly a user can enter the sequence. In some embodiments, the user 10can choose to play more than one line (or sequence) at a time. Payoutsmay also be provided for diagonal sequences across the multiple lines.Such a payout would encourage the player to play more than one line. Insome embodiments, a user “bingo card” may have a random sequencegenerated.

FIG. 8 depicts an exemplary interface screen 800 for use by a gamingagent 12 in at least one embodiment of the methods and systems disclosedherein. Agent interface 800 comprises game events 810 (e.g., specificscheduled sporting events) and game management options 820 (e.g., managegames, manual game update). Gaming agents may select a particular game(such as a Cubs vs. Phillies baseball game) and then select whether tomanage it manually or automatically. If the agent 12 selects manualmanagement, the agent 12 may need to update possible and actual outcomesmanually. In some embodiments, agent 12 may determine or updateprobabilities manually. If the agent selects automatically, then theserver 2 may update game information, e.g., via an automated data feed.

FIG. 9 depicts an exemplary interface screen 900 for use (e.g., by auser 10 and/or agent 12) in at least one embodiment of the methods andsystems disclosed herein. Interface 900 comprises a scoreboardcomprising status information about the game, such as the current score.Game options 920 enable users 10 and agents 12 to start a gamemanagement program that enables active betting markets associated with aparticular game. When a user 10 or agent 12 selects control panel 930,the interface 900 may enable users 10 or agents 12 to change settingsassociated with the game. Player selector 940 enables a user 10 or agent12 to change the identify of a particular player (e.g., the pitcher orbatter). As this information changes for each at-bat, the system mayrely on an agent 12 to update this information. Base Occupied option 950enables users 10 and/or agents 12 to indicate whether a runner is onbase, and at which base.

FIG. 10 depicts an exemplary interface screen 1000 for use in at leastone embodiment of the methods and systems disclosed herein. In someembodiments, the interface 1000 may be operated by server 2 and used byagents 12 to manage one or more gaming markets associated with an event.The interface 1000 may be comprised in a front-end component of server 2a in FIG. 2, which operates in conjunction with a back-end server 2 b.In some embodiments, interface 1000 may be used by users 10 to navigategambling options and place bets for one or more performance parametersin one or more events.

Interface 1000 comprises game information area 1010. Game action 1020buttons enable agents 12 and/or users 10 to activate all bets, freezeall bets, refresh all bets, or end the game. Other options may beconsidered. Game bets 1030 may identify all active or potential betsavailable (or that will be available) to users 10. Specific bets 1050shows the current status of specific bets. Betting market information1040 displays information about a specific betting market such asmaximum win, stop loss amount, odds, and hold percentage.

FIGS. 11-19 depict exemplary user interface screens for use in at leastone embodiment of the methods and systems disclosed herein. In someembodiments, the user interfaces may be displayed to users for viewing,configuring, and inputting betting information such as one or more bets.In some embodiments, the user interface of FIG. 11 may be displayed to auser, and the user may interact with the interface to specify betsrelating to a particular event such as a sporting event. In someembodiments, the interfaces may be periodically updated with new gameand betting information such as updated prices, odds, new bets, score,and other game and betting information discussed herein. The interfacesmay be used in conjunction with the system described herein to enableusers to view game and betting information and bet on in-game events.New betting markets may be created and generated on the user interfaceduring the game.

For instance, a betting market for a sixth inning of a baseball game maybe created and displayed on an interface at the end of the fifth inning,the beginning of the sixth inning, or another time.

Various items in FIGS. 11-19 may display betting information such as betamounts, odds, price, information, or other information. For example,various items in FIGS. 11-19 show either a positive number or a negativenumber, e.g., associated with a user-selectable bet on a particularevent outcome in a game, such as a bet that a run, goal, or other eventwill occur during a particular time period such as a particular inningor quarter (e.g., a current time period such as a current at-bat inbaseball or quarter in basketball).

In some embodiments, a positive number in such a user-selectable betarea may indicate an amount (e.g., in a currency such as dollars) that auser may win if the user places a bet in a predetermined amount (e.g.,$100) on a user-selectable bet associated with the area (e.g., a runoccurring during a particular half of an inning). Accordingly, forexample, the “+242” number in the upper left “Run” box in the “Run/NoRun” area 1130 of FIG. 11 may indicate an offer to the user to bet $100of the user's money (e.g., money accessible from or stored in an accountof the user in system 100) for the possibility of winning $242, e.g., ifthe selected outcome occurs (e.g., a run takes place during the bottomof the fifth inning of a particular baseball game). To place the bet,the user may select the “$242 Run” box. If a run takes place during thebottom of the fifth inning, the user may win $242 (e.g., and the usermay additionally receive a refund for or otherwise keep the $100 placedat risk in the bet). The user may also input other betting information,such as an amount of the user's bet.

In some embodiments, a negative number in a user-selectable bet area mayindicate an amount (e.g., in a currency such as dollars) that must beput at risk by the user in a bet in order to win a predetermined amount(e.g., $100) on a user-selectable bet associated with the area (e.g., arun occurring during an at-bat). Accordingly, for example, the “−312”number in the upper right “No Run” box in the “Run/No Run” area 1140 ofFIG. 11 may indicate an offer to the user to bet $312 of the user'sfunds (e.g., money accessible from or stored in an account of the userin system 100) for the possibility of winning $100, e.g., if theselected outcome occurs (e.g., no run takes place during the bottom ofthe fifth inning of the baseball game). For example, the user may selectthe “−312” Run box to place the bet. If a run takes place during thebottom of the fifth inning, the user may win $100 (e.g., and the usermay additionally receive a refund for or otherwise keep the $312 placedat risk in the bet).

Those of skill in the art will appreciate that the dollar amounts listedin a particular bet selection area (e.g., after the + or − sign, e.g.,in item in the diagrams) may indicate the price and/or odds of aparticular bet. In some embodiments a user may place a bet according tothe odds specified on the button in the user interface, but may place abet in an amount that is different from the amount on the bet. Forexample, a user may select a button with the “−312” representing theprice/odds of the bet, e.g., that the user must bet $312 for every $100the user would like to win (i.e., a 3.12 to 1 wager amount to winningsratio). The user interface may then display a betting screen thatenables a user to select an amount to put at risk. If the user wins thebet, the system may transfer a winning amount to the user based on theprice/odds. For example, if the user bet $3.12 and won, the system maytransfer a payout to the user in the amount of $1. (If the user paid thesystem $3.12, the system may also transfer back to the user the $3.12wagered amount.)

FIG. 11 depicts an exemplary interface screen for use in at least oneembodiment of the methods and systems disclosed herein. In someembodiments, the user interface of FIG. 11 may be displayed to a user,and the user may interact with the interface to specify bets relating toa game of baseball.

A game information area 1110 may display information about a game, suchas the teams or players playing the game, the current score (e.g.,broken down by game period such as inning or half), the current team onoffense (or at bat or the team in possession of a game ball), and otherinformation.

A “Run/No Run” area 1120 shows betting information concerning aparticular inning (or top or bottom of an inning) in a baseball game.For example, a user may select the icon in the upper left of the Run/NoRun area. Selecting the icon may trigger a bet (or trigger the displayof a betting interface that enables the user to configure parameters ofa bet such as an amount). For example, “Run +242” may indicate auser-selectable bet that a run will take place during the bottom of thefifth inning, whereas “No Run −312” may indicate a user-selectable betthat a run will not take place during the bottom of the fifth inning.Below those user-selectable bets may comprise bets for the nexthalf-inning, i.e., the top of the sixth inning. Odds and prices (e.g.,the positive and negative numbers indicated on each user-selectable bet)may be updated as the game goes on. Game information such as the eventsthat take place in the game and betting information such as the changingliability of the system for a particular selectable bet may affect theodds and prices, e.g., as described herein.

At bat betting area 1145 may comprise an area listing possible bets1150, 1155 concerning an outcome of a particular at-bat in the baseballgame. For example, a user may select area 1150 to bet that VictorMartinez will get to first base. Users may alternatively or in additionselect bet 1155 to bet that Victor will get to third base. Users mayselect other betting areas on the screen to make other bets, e.g., thatVictor Martinez will get to second, home, or out. Users may also bet ona specific pitch, e.g., that the next pitch will be a strike or a ball.

Three-inning area 1160 may comprise an area where users may bet on aportion of the baseball game, such as three of the nine traditionalinnings of a baseball game. For example, the system may create aseparate betting market for each 3-inning portion of the game, e.g., onemarket for innings 1-3, one for 4-6, and one for innings 6-9 (or 6 tothe final inning if there is overtime innings; alternatively, overtimeinnings may have a separate betting market created for them). Eachportion of the game (e.g., 3-inning portion) may comprise a separatemini-game for betting on various outcomes and/or parameters of theminigame, such as who will score the most runs (or most bases stolen, orleast errors, or other parameter) during those innings. Accordingly, ateam that wins the whole game may lose a minigame portion of the game(e.g., may lose innings 4-6 when those innings are consideredseparately).

Such “minigame” betting markets may be created at the end of a priorminigame (e.g., a market for innings 4-6 may be created after theconclusion of innings 1-3). In some embodiments, the market for asubsequent minigame may be created before the end. In some embodiments,the relevant bets and betting information may be displayed at the userinterface before the conclusion of the prior minigame. The odds for betsmay be updated as described herein.

Minigames may be determined for any sport. For example, a racingminigame may be a portion of laps of the race, a particular time periodof the race, or other metric in the race. For example, a 500 lap racemay have five 100-lap minigames, or 50 10-lap minigames. Minigameoutcomes may be determine by a variety of methods, such as who isleading at the end of the minigame, or who had the fastest average timeduring the minigame.

As shown in various other drawings of FIGS. 11-19, the “minigame”concept may be applied to other sports. In other words, parameters thatmay be typically bet on during a whole game may be the subject of a betfor a portion of the game considered in isolation. For example, usersmay bet on one quarter or half of a basketball game, football game,soccer match, or round of golf, for example.

As shown in FIG. 11, users may make a money line bet on the Yankees (byselecting icon 1170) or the Indians (by selecting icon 1165) concerningthe outcome of innings 4-6. Users may select option 1180 (e.g., byclicking in the area of 1180) to enable an “easy betting” feature. Auser may first configure an “easy betting” feature by specifying variousbetting parameters, such as a betting amount. If the easy betting iconis checked, then the system may automatically determine informationabout the user's bet (such as the betting amount) without prompting theuser for such information. For example, the “easy betting” feature mayenable a user to configure default parameters for one or more of auser's bets. This may facilitate the user's placement of future bets, asthe user may not need to specify such auto-populated informationseparately for each bet.

As shown in FIG. 11, users may make bets related to money line, runline,total runs, (e.g., during a full game or game portion).

Area 1175 may enable users to log out, select other games, view activebets, or view another interface for making current bets.

FIG. 12 shows betting information for a basketball game. As shown inarea 1210, the interface may show total points scored during eachperiod. Area 1220 shows bets that may be made for outcomes related tothe second quarter. Such bets may include, but are not limited to, betsrelated to the following: money line, spread, and total points.Additional bets related to these outcomes may be generated during thesecond quarter. For example, bets may become “outdated” due to very poorodds (e.g., a bet that one team will win the quarter when they are downby 20 points in the quarter with thirty seconds to go). New bets may becreated during the time period (e.g., basketball quarter) with more evenodds (e.g., a bet that the first team will win the quarter by 22 or 24points). Such bets may appear below the “outdated” bets. In someembodiments, the newer bets may replace the old bets.

FIG. 13 shows bets related to a hockey game. Icon 1310 may indicate thatone team (e.g., the Penguins) have a power play. Betting areas 1320 and1330 may enable users to bet on outcomes for the first period, e.g.,total goals during the first period. Other possible bets include, butare not limited to, puck line during the first quarter.

FIG. 14 shows bets related to a football game. Icon 1410 may show afirst down marker. To the left of the first down marker may be a“selected” area. The user may drag the “selected” icon to a position onthe field where the user wants to bet that the ball will travel toduring a particular portion of the game, such as a current drive, acurrent down, a current series of down (e.g., before the next first downor next possession), or quarter. Icon 1430 may show the number of yardsselected in accordance with the “selected” icon moved by the user. Icon1430 may also show the odds/price for that number of yards for theperiod specified. In FIG. 14, such selected yards may be the number ofyards selected for a particular drive.

Icon 1440 may be selected by a user to bet that the team in possessionof the ball will “not” get a first down. Another bet to the left of thisbet may enable users to bet that the team does get a first down (e.g.,during the current possession or before the other team takespossession).

FIG. 15 shows bets related to a race, e.g., a horse race. As shown aticons 1510, 1520, 1530, and 1540, users may bet on a particular horse(e.g., versus the field), a particular number of horses (e.g., versusthe field), the saddlecloth winner, or other outcomes.

FIG. 16 shows bets related to a tennis match. As shown in icon 1610, auser may select tabs to switch between sports (e.g., tennis andbaseball). Icon 1620 may show a user's current balance in an account,e.g., with system.

FIG. 17 shows bets related to a golf match. Bets may be per day of thematch, or per round, or for a whole tournament. Other bets may beconsidered.

FIG. 18 shows bets related to a soccer match (e.g., the World Cup).

FIG. 19 shows a betting window 1910 that may be triggered when a userselects a specific bet icon, such as Bet Now 1920. By confirming theidentified bet, the user may submit the bet into the system.

FIG. 12 depicts an exemplary interface screen for use in at least oneembodiment of the methods and systems disclosed herein. In someembodiments, the user interface of FIG. 11 may be displayed to a user,and the user may interact with the interface to specify bets relating toa game of basketball.

FIG. 13 depicts an exemplary interface screen for use in at least oneembodiment of the methods and systems disclosed herein.

FIG. 14 depicts an exemplary interface screen for use in at least oneembodiment of the methods and systems disclosed herein.

FIG. 15 depicts an exemplary interface screen for use in at least oneembodiment of the methods and systems disclosed herein.

FIG. 16 depicts an exemplary interface screen for use in at least oneembodiment of the methods and systems disclosed herein.

FIG. 17 depicts an exemplary interface screen for use in at least oneembodiment of the methods and systems disclosed herein.

In some embodiments, various devices and systems may be used toautomatically identify and track in-game events, such as the relativepositions of race participants at a specific time in (or throughout theduration of) a race. For example, the system described in U.S.application Ser. No. 10/604,451 by McCarthy et al. describes oneexemplary system for identifying and tracking event information in realtime or substantially real time, and for providing event information tousers, e.g., via rendered animation. The disclosure of the Ser. No.10/604,451 application is incorporated herein by reference in itsentirety.

What is claimed is:
 1. A method, comprising: receiving by at least oneprocessor state information of a live event in real time, in which thelive event comprises a sporting event played by human players accordingto predetermined rules that are used to determine at least one winner ofthe sporting event, in which at least a portion of the sporting event isplayed at a playing area; determining by the at least one processor aninitial state and a plurality of possible future states of a performanceparameter of the live event based on the state information; creating bythe at least one processor a first betting market for betting on atleast one of the plurality of possible future states, in which a firstone of the possible future states is defined by a first location of theplaying area, in which the plurality of users comprises a first user;causing, by the at least one processor, images associated with thesporting event to be displayed to the first user at a touch-sensitivedisplay device, the images comprising at least one image of the playingarea comprising an image of the first location; receiving by the atleast one processor from a first of a plurality of users a first betcomprising a selection of the first possible future state, in which theact of receiving the first bet comprises receiving indicia of a touchingof the image of the first location of the playing area corresponding tothe first one of the plurality of possible future states defined by thefirst location; closing by the processor the first betting market; afterclosing the first betting market, determining by the at least oneprocessor that the possible future state selected by the first useractually occurred; and automatically paying a payout to the first userbased on the first bet and the act of determining that the firstpossible future state selected by the first user actually occurred. 2.The method of claim 1, further comprising: automatically transmitting tothe plurality of users event information in real time, in which the actof transmitting comprises transmitting a live video of the live event tothe plurality of users in real time, and in which the live eventcomprises a sporting event having a playing field that is displayed atthe touch-sensitive display.
 3. The method of claim 1, in which thetouch-sensitive display displays a live video image of the sportingevent, the live video image comprising the displayed playing field. 4.The method of claim 1, in which the first bet further comprises aselection of a wager amount by the first user.
 5. The method of claim 1,further comprising: receiving from the first user a request for astatistic relating to the performance parameter; transmitting therequested statistic to the first user.
 6. The method of claim 1, inwhich the plurality of future states comprises a set of mutuallyexclusive outcomes of a performance parameter following the initialstate.
 7. The method of claim 1, further comprising: determining aprobability of occurrence for at least one of the plurality of possiblefuture states; and based at least in part on the probabilities,determining odds for betting on at least one of the plurality ofpossible future states.
 8. The method of claim 7, further comprising:determining a probability of occurrence for each of the plurality ofpossible future states; and based at least in part on the probabilities,determining odds for betting on each of the plurality of possible futurestates.
 9. The method of claim 1, further comprising providing to theplurality of users betting odds for the plurality of possible futurestates, in which betting odds are determined according to pari mutuelbetting rules.
 10. The method of claim 7, in which the probability ofoccurrence is determined based on information existing prior to a startof the live event.
 11. The method of claim 1, in which the informationexisting prior to the start of the live event comprises informationabout one or more players competing in the live event, in which theprobability of occurrence is based on one or more past performances ofthe one or more players in one or more prior competitions, and in whichthe probability of occurrence is based on a player's performance priorto the live event in at least one of the following performancecategories: batting average, points scored, yards run, number ofcarries, runs batted in (RBIs), bases stolen, home runs, pass completionpercentage, on base percentage, total bases per at bat, number oferrors, number of aces, double fault percentage, free throw percentage,number of rebounds, handicap, number of golf strokes, and number ofstrike-outs.
 12. The method of claim 10, in which the probability ofoccurrence is further determined based on state information of the liveevent received after the start of the live event.
 13. The method ofclaim 12, in which the probability of occurrence is determined based ona player's performance during the live event.
 14. The method of claim 1,in which the act of determining the actual future state of theperformance parameter comprises determining the actual future state ofthe performance parameter prior to an end of the live event.
 15. Themethod of claim 1, in which the live event comprises a game of football,and the plurality of possible states comprise mutually exclusiveoutcomes of at least one of a play, a set of plays before a first down,a quarter, a half, and a two minute drill.
 16. The method of claim 1, inwhich the possible future state selected by the first user comprises atleast one of: a number of yards, a type of play, a number of home runs,a number of base hits, a number of doubles, a number of triples, anumber of errors, a number of aces, a number of golf strokes by a playeron a single hole, a number of three-pointers, and a number of rebounds.17. The method of claim 1, further comprising: receiving a plurality ofbets on the plurality of possible future states; and determining oddsfor at least one of the plurality of possible future events based on atleast one of the number and amount of bets for and counter to the atleast one of the plurality of possible future states, in which thepayout is determined based on at least one of the number and amount ofbets that are for and counter to the first bet.
 18. The method of claim17, further comprising: determining aggregate information about theplurality of bets, in which the act of determining aggregate informationaggregate information about the plurality of bets comprises determininginformation about the percentage of users who bet on a specific possiblefuture state, in which the act of determining aggregate informationaggregate information about the plurality of bets comprises determininginformation about the percentage of users who bet on a specific possiblefuture state, and causing to be displayed the information about thepercentage of users who bet on a specific possible future state.
 19. Anapparatus comprising: at least one processor; and at least one memoryhaving instructions stored thereon that are configured to, when executedby the at least one processor, direct the at least one processor to:receive state information of a live event in real time, in which thelive event comprises a sporting event played by human players accordingto predetermined rules that are used to determine at least one winner ofthe sporting event; determine an initial state and a plurality ofpossible future states of a performance parameter of the live eventbased on the state information; create a first betting market forbetting on at least one of the plurality of possible future states, inwhich a first one of the possible future states is defined by a firstlocation of the playing area, in which the plurality of users comprisesa first user; cause images associated with the sporting event to bedisplayed to the first user at a touch-sensitive display device, theimages comprising at least one image of the playing area comprising animage of the first location; receive from a first of a plurality ofusers a first bet comprising a selection of the first possible futurestate, in which the act of receiving the first bet comprises receivingindicia of a touching of the image of the first location of the playingarea corresponding to the first one of the plurality of possible futurestates defined by the first location; close the first betting market;after closing the first betting market, determine by the at least oneprocessor that the possible future state selected by the first useractually occurred; and automatically pay a payout to the first userbased on the first bet and the act of determining that the firstpossible future state selected by the first user actually occurred. 20.An apparatus comprising: means for receiving state information of a liveevent in real time, in which the live event comprises a sporting eventplayed by human players according to predetermined rules that are usedto determine at least one winner of the sporting event; means fordetermining an initial state and a plurality of possible future statesof a performance parameter of the live event based on the stateinformation; means for creating a first betting market for betting on atleast one of the plurality of possible future states, in which a firstone of the possible future states is defined by a first location of theplaying area, in which the plurality of users comprises a first user;means for causing images associated with the sporting event to bedisplayed to the first user at a touch-sensitive display device, theimages comprising at least one image of the playing area comprising animage of the first location; means for receiving from a first of aplurality of users a first bet comprising a selection of the firstpossible future state, in which the act of receiving the first betcomprises receiving indicia of a touching of the image of the firstlocation of the playing area corresponding to the first one of theplurality of possible future states defined by the first location; meansfor closing the first betting market; means for determining that thepossible future state selected by the first user actually occurred afterclosing the first betting market; and means for paying a payout to thefirst user based on the first bet and the act of determining that thefirst possible future state selected by the first user actuallyoccurred.